Git Product home page Git Product logo

bombasticbob / x11workbenchproject Goto Github PK

View Code? Open in Web Editor NEW
3.0 3.0 0.0 3.92 MB

The X11 Work Bench, an IDE for working on X11 applications, with a simple C language toolkit that should be familiar and easy to use for old school GUI programmers (currently pre-alpha state)

License: Other

Makefile 0.48% C 86.42% Shell 1.26% M4 0.79% C++ 9.67% Roff 0.09% HTML 0.10% CSS 0.95% Starlark 0.26%
c cplusplus cross-platform freebsd ide language-toolkit linux posix pre-alpha programming x11

x11workbenchproject's People

Contributors

bombasticbob avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar

x11workbenchproject's Issues

Alpha - UI dialog boxes

required UI dialog boxes for Alpha:

  • File Open and Save As
    • list of extensions and file types in drop-down combo as a filter
    • easily navigated path tree
    • intelligent 'type in the path' functionality
  • Color picker
    • HSV and RGB with intelligent 'you changed it' handling
    • 256x256 SV picker
    • NNx256 H picker
    • color RGB as '#nnnnnn'
  • Font picker
    • list of available font faces/types with intelligent filtering
    • radio buttons for any, fixed only, or proportional only
      • interface should allow this to be pre-assigned and greyed so it can't be changed
    • system default fonts as a single checkbox
    • sample output showing actual text size for specific letters
    • (optional) enable/disable simple anti-aliasing for X11 fonts
    • returns an X11 Font Set
  • File properties ( see issue #17 )
  • System Properties ( see issue #17 )
  • Project properties
    • build environment
    • type of Makefile (editable, automake, shell, external tool, etc.)
    • list of targets (for more complex make environments)
      • separate debug/release build targets
      • specified targets for 'build' 'clean' 're-build all'
      • optional stuff that can be added to CFLAGS CPPFLAGS and/or LDFLAGS
    • tool paths (in case the project and/or option requires a cross-compiler, etc.)

printer support needs design and implementation

printer support needs design and implementation. in short, it should be possible to use an X11 device context or pixmap to display correctly onto a printer page. PDF output optional, but highly desired.

can rely on external libs via dynamic loading after checking for appropriate libraries, etc..

UI problem and feature deficiency rollup

bugs and deficiencies with UI in current version (2/1/2020)

  • multi-line edit, replace selection borks everything (single-line seems to be fixed now)
  • menu hotkey activation within menu context not working
  • menu bar does not change drop-down when mouse moves under a different menu bar item
  • menu popup containing popup is greyed and should have an arrow indicating it's a popup, but clicking displays 2nd popup underneath the entire menu (not to the side, as it should)
  • text invalidation not working properly - see issue #17
    • select via shift-up/down does not properly invalidate [but select rect is actually ok]
    • adding text at the bottom does not invalidate; however, text is added ok
  • scrolling list does not track mouse and scroll bar properly [quirky]
  • handling tabs and indents

Lower priority items

  • no 'splitter' for top level frames. at minimum need vertical splitter. Each 'split' window would have its own tabs and nav buttons for them.
  • tree list not implemented (will need for project view)
  • certain document properties should show up in the status bar, along with a button to edit them
  • need dialog resource, menu resource, and bitmap/icon resource editor
  • need to properly support drag/drop
  • need to support D-bus embedding at a minimum [both as client AND server]
  • need to support 'dynamic menu' like open doc list under 'Window'

some performance issues noted with message box open

noted some performance-related issues with opening message box, particularly the "about" message box. need to profile this, find out why.

this effect is amplified when using X11 on a remote display. This suggests it's a communications issue between the X library and the X server.

Alpha - need working editor

The editor's functionality needs to be complete.

  • Working user interface
    • ASCII and UTF-8 characters
    • Navigation keys work correctly (arrows, page up/down)
    • Mouse navigation works correctly (right/left click, highlight, scroll wheel)
    • popup context menu (right-click, shift-F10)
  • Conversion to/from UNICODE (UTF-16 specifically)
  • File save/open functionality for various file types (with data conversion, as needed)
  • File properties dialog box
    • line ending (LF, CR, CRLF, LFCR)
    • UTF-16 or ASCII/UTF-8 format in saved file
    • hard/soft tab and indent
    • reserved - programming language and/or file type
  • Ability to prompt for re-load when file is modified on disk
  • 'Undo/Redo' handler
    • this could be integrated into a keystroke macro processor at some point
  • simple autoindent
    • autoindent based on previous line's indenture
    • highlighted block indent and un-indent via Ctrl+[ and Ctrl+]

Other features "nice to have" for the alpha

  • Syntax highlighting interface for the 'Text Object' and/or the Edit Window or Child Frame
  • Track 'alternate view' changes, such as a 'resource view' and 'text view' for the same file
    • This could be implemented as a "shared data" API of some kind on a Child Frame
  • File properties saved/retained in project file
  • System properties dialog box
    • fonts
    • colors
    • default tab settings for known file types
    • reserved - custom file types
    • optional - default line-ending settings for known file types
    • global and per-user settings (for users that can edit system files)
    • other UI preferences
    • other (non-UI) preferences

(more to be added as I think them up)

'arrow' APIs don't completely "fill" the polygon when using grey color

for some reason, the 'fill' functionality does not properly fill the triangle shape when painting an 'arrow' using one of the four 'window dressing' API functions that paint arrows. These functions internally call XFillPolygon() which SHOULD fill the polygon; however, close inspection of a dark grey on light grey polygon show a light grey dot within the dark grey triangle. This problem does not appear to show up when BLACK is used to draw the triangle 'arrow'.

functions affected:

WBDrawLeftArrow(), WBDrawRightArrow(), WBDrawUpArrow(), WBDrawDownArrow()

'make -j' is now a built-in feature

The new configure scripts check for multiple cores, and automatically invoke 'make' with the '-j' flag that assigns one thread per CPU counted during the configuration process.

In short, this will at least speed up the build process by a factor of 2, assuming you have at least 2 cores in your CPU or VM.

If this causes problems, please comment here.

'make' with no target always re-links X11workbench, but should NOT

as a side effect of adding a pseudo-target to build JUST X11workbench (using the debug/release library created via the 'configure' settings), X11workbench will re-link every time. This is because it doesn't have a proper build dependency for lib/libX11workbenchToolkit.a

Additionally, when using 'make', the library will build 3 times. Normally this isn't a problem, as the configure options need to be used for X11workbench, while a separate debug and release version of the library need to be built for the 'install'.

Consider modifying the dependencies for 'install' vs a normal build to accomodate this.

New Feature "want list"

  • Single keystroke (alt + or alt - maybe) to increase or decrease font size
  • similar to turn syntax highlighting on and off
  • similar to switch between hard and soft tabs for a single open file.
    • tab settings need to be saved on a file-type and per-file basis, per-file taking precedent
  • file history
  • list of open documents within the 'window' menu (including for other main windows)
  • multiple main windows [especially when multiple desktops are involved]
  • drag/dock between main windows. also allow 2-step process for multi-desktop [switch to different main window basically]
  • project window separate from the others [as a main window], with one project per process
    • prominently indicate which project you're working on in all related main windows
    • opening different project opens new set of main windows with different process.
    • changing desktops (by default) moves all related windows to that desktop at the same time
  • * Accessibility * - see https://www.freedesktop.org/wiki/Accessibility/Walkthrough/

implement 'hard tab' as a series of hard tab chars that 'count' as spaces

implement 'hard tab' so that a ctrl+i (08H) is used to represent a 'tabbed white space', normalized to the correct column based on tab stops. As an example, if you set tabs at 4, and insert a tab at column 0, then 4 '08H' characters will be inserted, and the column will be set at 4.

to normalize deleting, tabs would have to be deleted "up to the next tab stop" for each delete operation.

Insert and delete operations would count as a single '08H' character for undo/redo. The undo/redo would have to normalize it before executing.

inserting spaces would have to overwrite tab characters up to the tab stop.

Alternate representation of hard tabs as a very thin 'arrow' when displaying.

Using this method would simplify length and column index calculations. The only 'fixes' would be in displaying, deleting, and inserting within a series of tab characters.

basic tab-based MDI frame window support 'under construction'

basic tab-based MDI frame window support 'under construction'.

  • Able to create an SDI or MDI frame
  • scrollable tabs across the top, just under the main menu, with left/right scroll buttons
  • ctrl+alt+pgup and ctrl+alt+pgdn hotkeys for left/right scroll
  • optional toolbar(s) located above the tabs (fixed, not dockable)
  • button on the tab bar to add a tab (equivalent to 'file new')
  • buttons on the tabs to close a tab (equivalent to 'file close')
  • able to 'drag' a tab to change the display order
  • support owned (child) windows within a 'WBChildFrame' that are automatically hidden/shown
  • support 'wizard mode' for the frame window (it's not much of a stretch to consider)
  • support 'property dialog' mode for the frame window
  • support 'dialog mode' for the child frames (a new derived type)
  • support multiple rows of tabs instead of just one, up to the limit of sanity

other requirements to be added

status bar support needs to be completed

currently, only a 'basic' implementation exists for the status bar. the status bar should be able to display status in multiple columns along the bottom, either right or left justified (or both at the same time), and with text inside the columns displayed left-aligned, right-aligned, or centered.

  • Multiple columns displayed
  • columns defined using status bar 'tab stop' information assigned to the Frame Window
  • columns are right-justified or left-justified, and re-position as window is re-sized
  • text within th columns can be displayed right, left, or center justified

Alpha - Basic toolkit features are functional

basic toolkit features must be functional for Alpha release

  • platform helper - abstraction of basic OS features
    • system information
    • processes
    • threads and synchronization
    • pointer abstraction for Event handling
  • text helper - API for string handling and related
  • file helper - API for file handling, listing directories, path searching
  • window helper - API for basic UI and event handling
  • clipboard helper - full clipboard support using Event-safe API calls
  • font helper - API for font selection
  • menu helper - API for menus (frame window and popup)
  • frame windows - SDI and tabbed MDI owner frame and child frames
  • dialog helper - dialog boxes, modality, text-based dialog resources
    • 'fixed' dimensions on dialog boxes
    • A simple dialog resource editor with drag/drop [to self] and other graphical features
    • reserved - resizable dialog boxes
      this has limited usefulness. See 'note 1' below
  • dialog controls - basic dialog control windows
    • ability for user-override of callback functions
    • standard and customizable properties associated with each control
    • visible/invisible and 'greyed' (disabled) capability
    • static text
    • static image, icon
    • edit text (single or multi-line)
    • push buttons
    • check buttons (including tri-state)
    • radio buttons
    • scrolling list box
    • static and editable drop-down combo box (other types not required)
    • tree control with collapsible members
    • special file list box and directory tree control that interact with one another
  • debug helper

additional 'higher level' features

  • edit window, based on child window, that supports text-based document editing

drop down combo boxes need support

drop down combo boxes need support. that includes simple list and editable combo boxes, as well as those that are "always dropped down".

'compile options' header needs to be installed

when the libraries are compiled and installed, programs that use them need to know what options were compiled into the static libraries, since this might change how the header files work.

To make sure this happens properly, the compiled options generated by 'autoheader' need to be installed along with the other header files. This also needs to be properly tested with various configurations.

Additionally, any options that are defined need to be marked as 'X11 toolkit specific' so that they dont' conflict with end-user's option naming.

Project View - basic requirements

'Project view' will need a few things in order to be useful

  • Two basic view styles
    • Project 'Tree' View, with multi-tab view in left side of split window, multi-tab edit on right
      • a menu or other means is needed to switch to 'editor' view easily (in lieu of un-dock drag)
    • 'Editor' view with multi-tab view for editor in main window, separate 'tool' window for tree views
      • seprate 'tool' window will need a button of some kind to switch to 'Tree' view
  • Project property sheet invoked via menu and hot-key
  • Ability to add/remove files or move between categories
  • Ability to specify output directories
  • per-build-type settings
    • Standard build types of 'debug' and 'release' on native platform
    • Custom build types (including platforms)
      • ability to specify compiler, linker, additional tools, command line options, etc.
  • Integrated debugger
    • default uses gdb
      • possible high level scripted interface for "other things"
      • possible kgdb (or similar debugger) interface for kernel development
    • On breakpoint, MUST unlock the GUI display
      • some kind of intelligent method of determining that this is necessary?
      • re-lock when resuming application?
    • watch lists, debugger command window, conditional breakpoints
      • initially display these in one or more separate toolboxes that show up in debug mode
      • when possible, handle this with some kind of splitter similar to project view, possibly horizontal OR vertical
    • breakpoint editor with 'clear all' and the ability to save/restore the list

implement syntax highlighting as an array of color information, with per-line indexes

implement syntax highlighting as an array of color information, with per-line indexes. Editing or inserting a line would have to make room for the color info, and temporarily lock out (and re-start) any background threads that are currently scanning the document.

color information would only be displayed when valid. Otherwise, use the default color. When "it becomes valid", the window will need to be invalidated. This should be made possible from a worker thread [currently there's no threading support for events].

multiple debugger support

X11workbench should support multiple types of debuggers. This should include:

  • gdb
  • bash (or sh)
  • perl
  • php

existing programs like xxgdb and ddd can be examined as to how to easily implement something like this. Care must be taken NOT to 'derive' anything, to avoid licensing issues (ddd is GPLv3).

for gdb, the application needs an easy-to-use GUI method by which you can send a debugging command and receive back debug information, for this to work at all.

Additionally, you should be able to interactively examine code/data and issue gdb commands (such as backtrace, print, single-step, and stack frame selection), and implicitly issue certain commands (like info, list, and enabling or disabling breakpoints).

shell and perl debug needs to interact similarly with their respective interpreters.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.