Activity for G4P
-
Anonymous created ticket #58
Request for Minor Enhancements to Droplist Control
-
G4P released /G4P V4.3.11.zip
-
Peter Lager committed [b98dae] on Code
V4.3.11
-
Quarks Processing modified ticket #57
Tool Tips show under other controls when nearby
-
In the next version of G4P (4.3.11) the sorting algorithm has been changed. It still sorts high>low Y but when controls have the same Y position they are sorted high>low X. It means that tips to the right or south of the control should appear over any controls in that area. The full solution would render all the buttons and then any tooltips. Unfortunately this would involve significant and messy code changes that would be detrimental to future maintenance. So having said that I will be closing this...
-
DropList Missing Items on Scroll
-
Fixed in V4.3.11
-
Droplist Scrollbar Thumb Size Issue
-
The thumb size represents the proportion of the list visible when the control opens. With large fonts and very long lists the visible portion is a very small proportion of the list so the thumb size is very small making it hard to drag. I will in
-
Droplist Scrollbar Thumb Size Issue
-
The thumb size represents the proportion of the list visible when the control opens. With large fonts and very long lists the visible portion is a very small proportion of the list so the thumb size is very small making it hard to drag. I will in
-
DropList Missing Items on Scroll
-
Tool Tips show under other controls when nearby
-
DropList Missing Items on Scroll
-
Tool Tips show under other controls when nearby
-
DropList Missing Items on Scroll
-
Anonymous created ticket #57
Tool Tips show under other controls when nearby
-
Anonymous created ticket #56
DropList Missing Items on Scroll
-
Matthias Wolf posted a comment on ticket #49
What a fine surprise and greatly appreciated! Thanks a lot!
-
Prevent missed mouseclicks
-
A button click event will now occur if the button is pressed and released while the mouse cursor is over the button. This enhancement should satisfy this issue. It will be available in 4.3.11
-
Dragging the scrollbar thumb is problematic
-
This has been fixed for version 4.3.11
-
Dragging the scrollbar thumb is problematic
-
The thumb size represents the proportion of the list visible when the control opens. With large fonts and very long lists the visible portion is a very small proportion of the list so the thumb size is very small making it hard to drag. I will investigate the problem further and see if I can come up with a workable solution.
-
Droplist Scrollbar Thumb Size Issue
-
Feature Request - Scrollbar Thumb with Mousewheel with Droplist
-
I covered this in the Processing forum here and I have not changed my mind. The changes you seek would change the generally accepted behaviourr of a drop-list control. It would not be backwardly compatible causing problems for other G4P users.
-
Anonymous created ticket #54
Feature Request - Scrollbar Thumb with Mousewheel with Droplist
-
Anonymous created ticket #53
Droplist Scrollbar Thumb Size Issue
-
Peter Lager committed [b67494] on Code
Released version V4.3.10
-
-
Peter Lager committed [b6968a] on Code
Pre-release 4.3.10
-
As you point out, this is covered in this discussion . Basically the problem is caused by having a text area with a height too small for the font size.
-
Request Jitter Removal on TextArea with Large Fonts/1 line
-
Text Input Filters for Textarea and Textfield
-
In many cases applying filters to these controls would require the displayed text to be changed during text editing. This will cause exceptions to be generated which will crash the sketch. An alternative is to use validation in the displayed text and indicate visually when it is invalid.
-
Prevent missed mouseclicks
-
Allowing slight movement between mouse down and mouse up actions when generating a control-clicked event, while desirable will not be implemented. If I had considered it when I created G4P in 2009 I would have included this feature but retrofitting it now is not cost effective in terms of effort required and risks breaking other functionality e.g. mouse drag events.
-
Using with Maven?
-
I have no experience with Maven so this will not be implemented.
-
Shortcut keys
-
Anonymous created ticket #52
Using with Maven?
-
Anonymous created ticket #51
Text Input Filters for Textarea and Textfield
-
Anonymous created ticket #50
Request Jitter Removal on TextArea with Large Fonts/1 line
-
Thanks – much appreciated! Looking forward to seeing the next release!
-
Shortcut keys
-
It's easy to extend controls with shortcut keys. Just capture pressed keys and call the respective clicked-Method. Sounds good in theory but G4P captures the events via Processing and then decides what to do with them. Adding shortcut key functionality to G4P would required significant effort on my part for minimal benefit to many users. This is especially true because this can easily be implemented by the user in their sketch code. An attribute like Text: &Ok in the builder, e.g. for a button, might...
-
Drawing a GDropList with empty item list raises NPE
-
Prevent missed mouseclicks
-
Shortcut keys
-
Peter Lager committed [4f4fa4] on Code
Release V4.3.9
-
-
Peter Lager committed [649e0c] on Code
Tool tips added - more testing and examples still to do
-
Peter Lager committed [6df911] on Code
Changes made towards next version
-
Peter Lager committed [36696d] on Code
Updated GAbstractControl
-
Peter Lager committed [feb98e] on Code
Backup
-
A better work round is to add an item after instantiation e.g. droplist.addItem(" "); and if you are using GUI Builder add this line to the customGUI() method. Normally I would expect users to populate the droplist before displaying it after all, what is the point of displaying a droplist with nothing to select?
-
GSpinner control update value report
-
Fixed in v 4.3.8
-
Anonymous created ticket #47
Drawing a GDropList with empty item list raises NPE
-
-
GSpinner control update value report
-
The problem is two fold 1) The control does not fire a changed event when the up/down arrows are clicked 2) In the library example the sketch is detecting the lost focus event and reporting vallue before it is changed. These will be fixed for the next release.
-
Anonymous created ticket #46
GSpinner control update value report
-
This feature already exists - see dispose() method. Sameple sketch - ```import g4p_controls.*; GTextField txf; GButton btnRemove; public void setup(){ size(240, 120); createGUI(); } public void draw(){ background(240); line(10,10,width-20,height-20); } public void txf_event_handler(GTextField source, GEvent event) { println("txf - GTextField >> GEvent." + event + " @ " + millis()); } public void remove_click(GButton source, GEvent event) { println("btnRemove - GButton >> GEvent." + event + " @ "...
-
delete/remove GTextField
-
Anonymous created ticket #45
delete/remove GTextField
-
G4P Controls in GPanel/Floating Panel enabled/clickable when the panel is initially collapsed ("Collapsed?" is ticked in the G4P GUI Builder)
-
This is now fixed for 4.3.7 released today should appear in Processing contributions manager in a couple of days
-
-
Version 4.3.7
-
Thanks for the detailed description of the problem, it has helped enormously. I have discovered the cause of the problem and I am currently testing the solution.
-
I will not be adding a listbox for G4P
-
G4P Listbox?
-
color() in GWindow always returns 0
-
I cannot reproduce this in Processing, in fact Processing fails to run when I tried using this.color(255,0,0) so G4P is not responsible for this issue. Just to let you know that you cannot access the color method using PApplet.color(...) because it is not a static method.
-
G4P Controls in GPanel/Floating Panel enabled/clickable when the panel is initially collapsed ("Collapsed?" is ticked in the G4P GUI Builder)
-
Anonymous created ticket #44
G4P Controls in GPanel/Floating Panel enabled/clickable when the panel is initially collapsed ("Collapsed?" is ticked in the G4P GUI Builder)
-
Anonymous created ticket #43
G4P Listbox?
-
Slight change for 4.3.7
-
Commit prior to release of 4.3.7
-
-
Various bug fixes
-
Marko created ticket #42
color() in GWindow always returns 0
-
Ah i see. In my case both stroke and fill is drawn before GUI, so first solution didn't help, but second completely solved my issue. Thanks a lot for explaining me what the problem is, now i understand Processing better, and i know where to look if something isn't right with my draw order. Great lib btw :) Cheers!
-
-
G4P draws its controls after the draw() method has finished ececuting so on 2D renderers that means the controls are on top. With 3D renderers the situation is much more complex and the problem is not down to G4P or OpenGL but rather on howProcessing (PS) draws lines (strokes). To improve renedering speed PS draws all fills then and only then draws the strokes, so lines will appear above the controls. In fact if you add a rectabgle with fill and stroke to your sketch you wiill see the button over...
-
G4P draws its controls after the draw() method has finished ececuting so on 2D renderers that means the controls are on top. With 3D renderers the situation is much more complex and the problem is not down to G4P or OpenGL but rather on howProcessing (PS) draws lines (strokes). To improve renedering speed PS draw s all fills then and only then draws the strokes, so lines will appear above the controls. In fact if you add a rectabgle with fill and stroke to your sketch you wiill see the buton over...
-
G4P draws its controls after the draw() method has finished ececuting so on 2D renderers that means the controls are on top. With 3D renderers the situation is much more complex and the problem is not down to G4P or OpenGL but rather on just on Processing (PS) draws lines (strokes). To improve renedering speed PS draw s all fills then and only then draws the strokes, so lines will appear above the controls. In fact if you add a rectabgle with fill and stroke to your sketch you wiill see the buton...
-
G4P draws its controls after the draw() method has finished ececuting so on 2D renderers that means the controls are on top. With 3D renderers the situation is much more complex and the problem is not down to G4P or OpenGL but rather on just on Processing (PS) draws lines (strokes). To improve renedering speed PS draw s all fills then and only then draws the strokes, so lines will appear above the controls. In fact if you add a rectabgle with fill and stroke to your sketch you wiill see the buton...
-
@quark-s Completly forgot about different renderers, sorry about that. Im using P3D. Your same example with P3D will demonstrate the issue. Am i doing something wrong there? Im also working in IntelliJ if that makes any difference. Code i tried: import g4p_controls.GButton; import processing.core.PApplet; public class Main extends PApplet { GButton btn; public static void main(String[] args) { String[] appletArgs = new String[]{"Main"}; PApplet.main(appletArgs); } public void settings() { size(150,...
-
V4.3.5
-
GUI is not drawn on top
-
Nothing to fix.
-
This has never been reported before so I tried this sketch using both JAVA2D and P2D renderers import g4p_controls.*; GButton btn; void setup() { size(150, 150, P2D); // Also tried JAVA2D btn = new GButton(this, 10, 20, 130, 30, "Quark!"); } void draw() { background(255); noFill(); stroke(255, 64, 255); strokeWeight(10); beginShape(); curveVertex(84, 91); curveVertex(84, 91); curveVertex(68, 19); curveVertex(21, 17); curveVertex(32, 100); curveVertex(32, 100); endShape(); } and the button appears...
-
Anonymous created ticket #41
GUI is not drawn on top
-
Add a revers option to GKnob rotation direction
-
This has been implemented by allowing negative sensitivity values. Will be available in 4.3.5
-
Anonymous created ticket #40
Add a revers option to GKnob rotation direction
1 >