AltME groups: search

Carl's Rebodex has something like what you describe.  It filters 
the data in a list rather than a drop-down type widget, but that 
would be easy enough to change.

different point - is it necessary for the highlight to be removed 
from a text widget if the focus has gone elsewhere?
It doesn't happen with list widgets

A set-info func is in the works, but requires some rather extensive 
widget changes (e.g. drop-list and edit-list are different widgets 
at present).

Ashley, the tree widget is not indexed here http://trac.geekisp.com/rebgui/wiki/WidgetList
though it appears in the source code list

hi every one . i would like to know if it is possible to change color 
of row in widget table ? . or if i must prefer use table-list of 
shadwolf ?

shadwolf do you have a compatible widget table-list with rebgui-bluid 
114 thank you in advance ?

however main goal of rebGUI was to provide a cool widget enhancement 
library for VID propose a "example" set of widget people want to 
use the most in their software ( well that list of widgets can be 
found in any advanced graphical library such as GTK+ winap32 aqua 
QT WxWindows Tcl/tk etc...)

RebGUI v2 RC1 (build 200) uploaded to SVN

Focus of this version has been:
	* Make it look good (color scheme based on Windows 7)

 * Take into account OS sensibilities (different corner rounding, 
 window colors, system fonts)

 * Get rid of the cruft (removal of little-used widgets and options)
	* Improve tabbing
	* Make it load and run faster



Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?



Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color



Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font



Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]


WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

hmm, SVN says:

RebGUI v2 RC1

Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?

Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color

Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font

Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]

WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

title-group and image RebDoc section depend upon image ...
 Fixed in next build
scrollbars are behing a little weirdly
 ... noted

basically when one specify [button 100] one get old [button 103] 
but that's ok if we know it
 ... ah, I understand the issue now. Fixed in next build.

I hope somebody else was using this feature so it's not only me using 
before and wanting it.

 ... don't worry, I think the issue is that table needs to differentiate 
 between a selected row and a row that has focus. This was not an 
 issue in previous versions as table was not a tabbable widget. Will 
 be fixed in a future build.

Drop-list and edit-list cannot be closed by clicking elswhere but 
this is still to be fixed, isn'i it.
 ... on the list to fix
Another little observation.

 ... that's an interesting bug and I have no idea at this stage why 
 the 2nd case doesn't work. Needs further investigation.


Good work marek (and others) ... we're slowly but surely ironing 
out the issues.

Maybe tree widget could benefit from row coloring too? Would look 
consistent with table and text-list.

nothing pops up when clicking the button, why?

 ... the display function exits if it hits a duplicate window title 
 (before calling layout) ... this means you don't have to worry about 
 the user hitting a button that calls a display multiple times and 
 getting multiple (near identical) windows popping up!

tree widget could benefit from row coloring too?

 ... it will, once I've rewritten it to use the same face-iterator 
 func that table and text-list use (which means it'll get all the 
 extra goodies like auto-slider support as well!

Build 211
- Moved base objects from ctx-rebgui to system/view
- Removed all dependencies on View/VID mezz code
- Rewrote and added show-popup & hide-popup functions
- Removed style widget
- Inlined popup logic
- Converted internal images from base 16 to base 64
- Cursor keys now work in choose (drop-list, edit-list & menu)
- pad option in layout enhanced to accept pair! (pixels)
- Added tooltips to tool-bar
- Added request-edit
- Improved resize logic
- Fixed request-dir (resize bug)
- Fixed slider (resize bugs)

Any suggestions for a replacement for the VID toggle?

 ... isn't the toggle just a drop-list less the drop component? It's 
 a fairly trivial widget to add to RebGUI, but it's not a widget I've 
 seen in any Windows or Mac apps. What do folks think about this widget 
 from a UI POV?

Build 213
- layout moved to global context
- renamed request-edit to editor
- renamed set-enable to enable
- renamed set-disable to disable
- added in-widget function
- enable/disable now accept block of faces
- fixed arrow/list bug
- changed popup auto-hide from away to click
- fixed menu
- added toggle widget
- changed hard-coded green/red to use colors/true & false
- updated tour.r and RebDOC.r

Before one touches widget list, simply - do %create-distribution.r 
- fails because of missing 2 files, as I stated before. I hope, I'm 
not doing anything wrong getting this result. I should eventually 
overcome this problem temporarily, until it's fixed in next release.

>>display/dialog "test" [drop-list data [1 2 3]]   ;; no problems, 
build 215, linux Mint  

>>display/dialog "test" [edit-list data [1 2 3]]   ;; big problem 
here 


When trying to enter text into edit-list widget the window magically 
disappears.

Can anybody confirm, please. Am I doing anyting wrong? Will it ever 
work? Ashley?

UI question. What's the "standard" way to deselect a selected table/text-list 
row. I've seen:

	a) click the selected row (i.e. toggle mode)

 b) click outside the parent widget (i.e. deselect on focus change)
	c) don't allow it (the current RebGUI behavior)


I can see problems with each approach, but c) requires another widget 
(typically a button) to produce the desired behavior.

I will try my luck again with this 2 items.


When using edit-list or drop-list, there is a way to crash it. Just 
click on the widget, hilight any line on the list and press <TAB>.

>>display "" [edit-list data [1 2]] do-events ;;-> stack-overflow 
error message pops up.


Table widget has different gap in the last column on the right without 
and with the scroller. It' only cosmetic thing and maybe it is customary 
to be like that.

>> display "" [table options ["a" right 1.0] data [1] table options 
["b" right 1.0] data [2 3 4 5 6]] do-events

Can anyone confirm, please. Ashley?

As append-widget removal was oversimplification imo, especially for 
the widget authors, I created short script, which kind of automates 
the process ....

1) Save the script, e.g. make.r, into the RebGUI root dir

2) create one file, called %my-widget-list.r, containing unnamed 
block, containing file-names. Your widgets can be placed anywhere

3) create backup of %rebgui-widgets.r, call it %rebgui-widgets.old.r, 
in order to be able to easily "remove"  widgets by commenting them 
out in file 2)

Here's the script:
REBOL []

;--- to enable removal of unwanted own widgets, create
;--- copy of rebgui-widgets.r into rebgui-widgets.old.r

;--- remember to do so, when official distro release contains new 
widgets!
if exists? %rebgui-widgets.old.r [
  write %rebgui-widgets.r read %rebgui-widgets.old.r
]

;--- load list of widgets you want to include
;--- file containing un-named block of list of files to include
widgets-to-include: load %my-widget-list.r

template: "^-#include %widgets/^/"

;--- read RebGUI widget list (%rebgui-widgets.r)
tmp: read %rebgui-widgets.r

widget-buffer: copy "^/"

foreach widget-filepath widgets-to-include [ 

   widget: last split-path widget-filepath

   ;--- copy widget to the widget-directory
   write join %widgets/ widget read widget-filepath
  
   ;--- build string containing widget names you want to add ...

   ;--- but only when not already on the list - prevent duplicate entries
   if not found? find tmp widget [

        append widget-buffer (head insert find/tail copy template "/" widget)
   ]

]

;--- append to RebGUI widget-list (%rebgui-widgets.r)
change back back tail tmp (append widget-buffer "]")
write %rebgui-widgets.r tmp

;--- rebuild RebGUI distribution ...
call "create-distribution.r"

So, I can feed this widget 18,000 entries which I don't think you 
can with the edit-list.

the second categories countains the set of high level widget wich 
include a lot of time of  developement and though about how to give 
them flexibilities and extensibilities  not to end with a list-view 
widget that is able to display nothing but text like in R2.  Those 
widgets and widget set should be able to evolve in time and ofcourse 
without impling a redistribution of the complete R3 view stuff.exe

There is now Carl's blog upon how to easily list styles in R2. I 
posted corresponding R3 code, although it might be preliminary:

foreach [name obj] guie/styles [print [name "-" obj/about]]

But - I would like the GUI team to think about following aspects:


Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed. OTOH those are legitimate styles, from which you might 
want to derive something, or just being able to change their aspects. 


So, I propose to resolve this situation somehow. The implementation 
is up to gurus, just few wild ideas:


- use tagging - tag style as 'main/root/parent, whatever - but - 
that introduces another field to the styles? Maybe not, because I 
expect some tagging system being available anyway?


- create guie/widgets, e.g.: guie/widgets: [table [table-cell table-header 
table-row] - that way we will be able to list just/only widgets as 
table, not having the list poluted with widget internals


- the above aproach might not work well in the case, when you aproach 
styles more as a CSS, not as widgets. Because - even e.g. 'table-cell 
might be derived from a totally different style, e.g. a box, or field, 
so I have no idea of how to keep track of those dependencies, but 
this is the area I leave for gurus to think about. E.g. someone changes 
box style and your table is influenced and user might be confused, 
why it happened. But I expect style/parent or something like that 
being available?

when a concept of default size is there, that is usually what you 
want the pair to be.  when it goes beyon min or max bounds, usually 
you want to push these to at least match the default size...   the 
developper is expressly asking for an adjustment to the default.


the thing is that when a widget is in an auto-resizing layout, asking 
for 100x100 might not actually give you that size, because all the 
widgets are subject to the layout in which they are displayed.  in 
row/columns, you will be subject to equalizing other lateral sizes 
in the list and may be given more space in the longitudinal size, 
such that in fact, your button may be larger than what you asked 
for.


the only way to force a 100x100 button is for the gui to support 
static sizing within a dynamic layout, or support max-size and set 
it to the exact same as default size effectively making it a static 
sized button.

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

Red/System [ ]

#include %GTK.reds

argc-reference: declare integer-reference!
argv-reference: declare handle-reference!
argc-reference/value: system/args-count
argv-reference/value: as-handle system/args-list

_gtk-begin argc-reference argv-reference

_window: gtk-new-window gtk-window-top-level
_label: as gtk-widget! 0

either as-logic _window [
	_label: gtk-new-label "Good riddens!"

	either as-logic _label [
		gtk-append-container  as gtk-container! _window  _label
	][
		print "Failed to create label.^/"
	]


 g-connect-signal  as-handle _window  "destroy"  as-integer :gtk-quit 
  none
	gtk-show-all _window
	gtk-do-events
][
	print "Failed to create window.^/"
]