I don't work with Graphical interfaces very much, most of my experience has been with Java. I realize the operating system provides some "native" controls that allow you to do things. What if I want to do things that are a little more fancy but feel like the native control?
What I'm thinking is having the simplicity of editing in a TextArea while provide the ability to collapse lists just like a tree. I would also like to be able to display text between lines that the user could click, it should be aligned under the right most text and be smaller.
I'm not thinking in terms of any language or GUI library. Just wondering how to go about creating something like this. Would I overlay some drawing onto the TextArea which would scroll with it? Would I use something like Cairo and build my own text field losing built in copy and paste...
What do other text editors use that allow them to fold code?
There is no universal solution to this. It varies depending on GUI. Every GUI has a different way of responding to user events such as mouse clicks, keyboard shortcuts, etc. There is no universal approach to this.
Related
I want the user to enter text in a text box (such as a login text box on some site).
I tried to search in text() bibliography and other similar functions.
This guy seems to have figured it out: http://www.sojamo.de/libraries/controlP5/. Look for the textArea control.
If you don't like this, I read that the g4p library had something like an inputbox. Otherwise you will have to draw it yourself (which would be a nice exercise) using keyboard inputs and the like.
What you're describing is called a graphical user interface, or GUI. There are many ways to approach this problem:
Code it yourself. Use something like the rect() function to draw a text box, and the keyPressed() function to detect key presses.
Use a library. The Processing libraries page lists several GUI libraries. Try each of them out and see which one you like best.
Use a more general GUI library. If you're deploying as Java, then you might use Swing or JavaFX. If you're deploying as JavaScript, then you might use HTML elements.
Any of the above might work, and which approach you choose depends more on you, your context, and your preferences. We can't tell you which is best, because it's all up to what you prefer.
We are all familiar with text highlighting. You hover over any "text" in any application on your Windows OS, your cursor changes into an I-Beam, and you can click and drag across the text to Highlight it. This highlighted text can be copied to the clipboard for later use.
Some applications modify the default highlighting behavior by changing color, opacity, or even shape. Some applications allow for column selection (e.g. Visual Studio "alt-click-drag" creates box like highlighting)
I have scoured the depths of the internet, but I can't seem to find a solid source of information that would explain how one would modify the behavior of text highlighting.
How would I implement column/block text selection, and modifying the appearance of the highlighted text in a compiled application.
Since applications can do this in various custom ways, there is no single solution to change how all of them style text selections.
Many will rely on the current color scheme (using GetSysColor) to determine the highlight colors. So you could modify the scheme and maybe affect the colors used for many applications.
To do this programmatically, you would use SetSysColors to change the COLOR_HIGHLIGHT and COLOR_HIGHLIGHTTEXT values.
Other applications might rely on the current theme (using GetThemeColor). To affect those you'd have to select a different theme that has the colors (and perhaps other styling choices) that you want.
A lot of apps use their own hard-coded color schemes, so you won't be able to programmatically at all.
I'm not sure what you mean with the web application part of your question. A web application is some HTML, JS and CSS that make the browser interact with your system. Any custom selection (coloring) logic that the web application provides, has to be implemented by the browser.
Also you have to realize that "(text) selection" is an rather virtual principle. An application can just render a colored shape (like a blue rectangle) and copy something to the clipboard when it receives a WM_COPY message.
Windows provides in basic substring selection functionality for (rich) edit controls (i.e. start and end position), but for something custom like column selection, custom code is required.
Read more about this in Making a rectangular selection in a RichTextBox with Alt-Left-Mouse sweep?.
I would like to draw a popup in X11. Something like the slider that appears in KDE and GNOME when you press volume or brightness control buttons. This is what it looks like in GNOME:
What library should I use to create such popups (unlike normal windows they should be without borders, etc. and possibly with some transparency)? Would be nice if there were bindings for Python.
This is done in GTK+. The easiest thing may be to find the code that creates that and copy what it does (my system has a different volume notifier, I'm not easily finding the code for that one).
Roughly what you'd do is create a GtkWindow, set_decorated(FALSE), set_position(GTK_WIN_POS_CENTER), something along those lines.
I'm not sure of the best set_type_hint(). Maybe TYPE_HINT_NOTIFICATION or TYPE_HINT_SPLASHSCREEN. If you do set the type hint, it may not be necessary to set_decorated or set_position since the type hint may imply those with many window managers.
I am thinking of implementing a ribbon GUI in one of my apps and of course want to adhere to the MS Guidelines so it feels like a normal ribbon, etc. But I'm trying to figure out how to solve a specific problem in dynamically changing the ribbon.
I'm creating a concept game editor, please no question on why a ribbon as this is purely a concept idea, but the application will have many editors (2D, 3D, Code, etc) and for each one the GUI should adapt and display relevant controls i.e. in the 2D editor maybe a paintbrush, on the 3D many pan and rotate tools.
Given the ribbon guidelines it makes sense to the Home menu to contain the most common tools, but only for the type of object being edited (rotate makes no sense for 2D or Code!).
I initially thought it could have one window per editor but this makes a real mess and I'd rather have lots of tabbed editors so you can flick through them fast like in eclipse etc. Also all editors save back into one file so it makes sense to have one application window to keep this metaphor for the user.
I was thinking I could dynamically change the ribbon tabs depending on what type of editor the user had open (tabs may appear/disappear, content on the Home tab etc would change) but then this breaks the MS guidelines of:
"Controls displayed in a group MUST NOT change as a result of selection. If a control is not active, then the control MUST be grayed out, rather than removed from the group"
"The tab selected on the Ribbon MUST NOT automatically switch as a result of user selections made in the 177 document (except as noted in the Contextual Tabs section)."
I understand the reasoning behind the guidelines but im not really sure how to get the ribbon to feel right in this situation:
Change the content of the tabs
depending on editor type (goes
against the guidelines)
Have a tab
per editor type (but what if i end up
with 15 editor types!)
Have a very
generic ribbon and move specific
editor operations to a side bar or
something (not the best GUI design)
Use contextual tabs for each type of
editor (better solution but means you
always have one contextual tab open!)
Any other ideas/solutions would be greatly appreciated as I must use a ribbon and must use it for this type of application!
If you are providing a tab that is editor-specific, I suppose you could lay it out in the way that is best for that particular editor. That means that controls are going to move around occasionally, if you use the same tab for the other editors. It doesn't seem practical to gray out the controls that don't apply to any particular editor, if it's going to cause a lot of clutter.
On the other hand, graying out controls does have the benefit of keeping each control in exactly the same physical place on the tab. Do not underestimate the power of this. There's nothing more aggravating than expecting a control one place, and having it suddenly move someplace else (or disappear altogether). The graying out is a clear indication that the grayed control does not apply in this context.
So depending on how different the controls are for each editor, you will have to decide which approach is less disruptive: to gray out the unneeded controls, or to provide a fresh layout for each editor.
It doesn't seem workable to open a tab for every editor that's open, since there will be many tabs that are useless when the user is in a specific editor.
If possible, enlist the help of some volunteers or beta testers, and do some paper prototyping with them to see which approach resonates better with them.
I'm facing the same design problem. One idea is to use different frame for each editor and a different specialized ribbon in it. Because there's little point in a big ribbon with 10 tabs full of disabled commands.
P.S. I'm investigating another idea - to use certain tabs clicks for triggering different editor modes. (I'm designing a house drafting program.) In example:
Clicking "Home" tab switches to the
plan editor to the edit the house
from "top" view;
Clicking "Wall"
tab switches to the wall editor
where you can edit the wall shape
and featues.
Clicking on other tabs
may not change the current editor.
They can show up other non-modal
commands that are related to the
whole document (or something else),
not about the current editor mode
itself.
How would I go about implementing something along the lines of "scrubby sliders", like in Photoshop and quite a few other image-processing applications?
They are slightly hard to describe.. basically you have a regular numeric input-box, but you can click-and-hold the mouse button, and it functions like a slider (until you release). If you click in the box, you can select text, edit/paste/etc as usual.
The Photoshop docs describe it, and I put together a quick example video (an example of the sliders in Shake)
Another similar implementation would be the jog-wheel in Final Cut Pro, which functions similarly, without the numeric readout being underneath.
I can't seem to find any mention of implementing these, although there is probably alternative names for this. It is for a OS X 10.5 Cocoa application.
It is for a colour-grading application, where a user might need to make tiny adjustments (0.001, for example), to huge adjustments (say, -100 +100) on the same control. A regular slider isn't accurate enough over that range of value.
Copy-and-pasting values into the box would be a secondary concern to scrubbing the values, and the Photoshop/Shake setup really well. The unobviousness of the control is also of a low concern, as it's not a "regular desktop application"
I've encountered those. They suck, because they prevent the user from dragging to select the text of the number.
A better idea would be a miniature slider beneath the field that expands to a full-size slider when the user holds down the mouse button on it and collapses back to its miniature size when the user releases the mouse button. This way, the selection behavior is still available, but you also provide the slider—and in a more obvious way.
There's no built-in class in Cocoa for either one. You'll have to implement your own.
I doubt that this exists in Cocoa framework. As far as I remember it is not mentioned in the Apple Human Interface Guidelines.
You can develop one yourself by using a custom view and tracking mouse events (-mouseDown:, mouseUp:, -mouseDragged:).