[Pgui-devel] mem leak??
hi Micah,
Sorry to ask this problem, as i asked before.
The DialogBox will memory leak?? It should be the dialog title occure.If run
dialogdemo in apps, will case memory leak.
I find there resone, but can't not fix in right.
I fixed it in a urgly way like flowing, and run it had a week, it did can work!
please tell me the right way ??? thanks
#ifdef CONFIG_URGLY_FIXED
#define SUBDIV_AVAILE (((self->in) && (self->in->div)) && !(self->in->div->div) &&
(self->sub))
#endif
void dialogbox_remove(struct widget *self) {
if (DATA->title)
handle_free(self->owner, DATA->htitle);
g_free(DATA);
#ifdef CONFIG_URGLY_FIXED
/*why is will not equaue, sanit Handinfo Ltd. ???*/
if (SUBDIV_AVAILE)
{
self->in->div->div = self->sub;
}
#endif
WIDGET_REMOVE_PARENT;
}
sanit+,~wzf¢+,¦ì¢·o$áyyézW(ëhç¤
æ¯zxm¶ÿ¶§Ê&þÇÏèz÷¥¨¥x%ËOèz÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþ.ׯz
[Pgui-devel] other bugs
Hi, Micah
There are some other bugs, we fixed.
1. in widget/textedit_logical.c, old code in most skins cause pgserver crashed.
#ifdef CONFIG_HANDINFO_FIXED
g_error text_backend_build ( text_widget * widget,
s16 w,
s16 h ) {
#else
g_error text_backend_build ( text_widget * widget,
u16 w,
u16 h ) {
#endif
2.in widget/textedit_logical.c, we must judge if the buffer had chars.
g_error text_backend_set_selection ( text_widget * widget,
struct pgstring * text ) {
g_error e;
#ifdef CONFIG_TEXTEDIT_WCHART
wchar_t * wBuffer;
#ifdef CONFIG_HANDINFO_FIXED
if (!text->buffer || text->num_chars == 0)
{
return success;
}
#endif
}
3. in gcore/pgstring.c pgstr_utf8_seek function, we handle negative char_num, that be
used in textbox widget if we want to support utf8 code (Chinese). but this code is vey
ugly and slow and it can work.
void pgstr_utf8_seek(const struct pgstring *str, struct pgstr_iterator *p, s32
char_num, int whence) {
int num = 0, savenum = 0;
struct pgstr_iterator temp_iterator;
switch (whence) {
case PGSEEK_SET:
p->offset = 0;
break;
case PGSEEK_END:
#ifdef CONFIG_HANDINFO_FIXED
if (str->num_chars == 0)
p->offset = 0;
else
#endif
p->offset = str->num_chars - 1;
break;
}
/* FIXME: handle negative char_num by sanit Handinfo Ltd.*/
#ifdef CONFIG_TEXTBOX_SUPPORT_UTF8
if (char_num >= 0)
{
#endif
while (char_num) {
if (!pgstring_decode(str,p))
return;
char_num--;
}
#ifdef CONFIG_TEXTBOX_SUPPORT_UTF8
}else
{
if ((num = char_num + str->num_chars) <= 0)
p->offset = 0;
else
{
temp_iterator = *p;
temp_iterator.offset = 0;
/*FIXED ME this is a very urgly code, sanit */
savenum = str->num_chars;
while (savenum) {
if (!pgstring_decode(str,&temp_iterator))
return;
if (temp_iterator.offset == p->offset)
{
break;
}
savenum--;
}
if (savenum == 0)
return;
num = str->num_chars - savenum;
temp_iterator.offset = 0;
while (num) {
if (!pgstring_decode(str,&temp_iterator))
return;
num--;
}
*p = temp_iterator;
}
}
#endif
}
sanitN¬±ùÞµéX¬²'²Þu¼)äç¤Yé\¢g¢½éá¶ÚþØbH zG(û > ¢uëÞf¢)à+-> ¢uëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣú`º'^½é
[Pgui-devel] Desktop-style window management
Hi folks, I'm evaluating which GUI to port to a non-unixstyle multitasking OS with limited posix lib support. Although the CPU performance is more like "embedded", the use is a highresolution desktop rather than a small display. Framebuffer implementation seems feasible, but the PDA-style windowmanagement of picoGUI is not suitable. Apart from windowmanagement, the picoGUI architecture seems to fit quite good. In the FAQ I read: [...] in theory PicoGUIshould work great on the desktop once more apps and drivers are written. Even though PicoGUIis usually used without overlapping windows, it does support them, and the PicoGUIserver is very scalable. There is already work in progress on a Linux-based OSthat uses PicoGUIrootless on X as its native GUI, so PicoGUIapps can run side-by-side with X apps in overlapping windows. [...] Does this mean overlapping PicoGUI windows are only supported via X, not on bare framebuffer without X? Is there work in progress for PicoGUI desktop-style windowmanagement, esp. overlapping windows for multitasking applications? Sorry if this forum is not the right place for my sort of question. Maybe you can give me a quick hint, thanks a lot. Regards, Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
On Mon, Jan 06, 2003 at 12:32:43PM +0100, Peter Graf wrote: > Hi folks, > > I'm evaluating which GUI to port to a non-unixstyle multitasking OS with > limited posix lib support. Although the CPU performance is more like > "embedded", the use is a highresolution desktop rather than a small display. If you're using too big of a display on a small CPU, things will be slow without hardware acceleration. If there's any acceleration hardware, picogui should be able to take advantage of it with the right driver. > Framebuffer implementation seems feasible, but the PDA-style > windowmanagement of picoGUI is not suitable. Apart from windowmanagement, > the picoGUI architecture seems to fit quite good. > > In the FAQ I read: > > [...] in theory PicoGUIshould work great on the desktop once more apps and > drivers are written. Even though PicoGUIis usually used without overlapping > windows, it does support them, and the PicoGUIserver is very scalable. > There is already work in progress on a Linux-based OSthat uses > PicoGUIrootless on X as its native GUI, so PicoGUIapps can run side-by-side > with X apps in overlapping windows. [...] > > Does this mean overlapping PicoGUI windows are only supported via X, not on > bare framebuffer without X? For now yes, but this is planned to change. Part of this is the App Manager's responsibility, and part of it is in the video driver and rendering engine. Currently PicoGUI's built-in rendering engine doesn't support overlapping correctly. However, there is a 'rootless' mode where all top-level windows are managed by an external system. This lets picogui do overlapping in X. On the framebuffer, you could do the same thing using DirectFB. PicoGUI has no DirectFB driver yet, but it wouldn't be much work to write one. There are plans to rewrite PicoGUI's rendering engine using a pretty nifty new algorithm that would make all drawing more efficient, and support full overlapping. Once this is done it would be easy to remove DirectFB if desired. > > Is there work in progress for PicoGUI desktop-style windowmanagement, esp. > overlapping windows for multitasking applications? Assuming picogui supported overlapping windows, either by running on top of X or DirectFB, or with the new rendering engine, you'd just need an app manager to handle overlapping. This would consist of writing a widget that implements a traditional draggable window frame, and a simple app manager that uses that widget. > > Sorry if this forum is not the right place for my sort of question. Maybe > you can give me a quick hint, thanks a lot. Nope, this is the perfect place to ask such a question :) > > Regards, > Peter --Micah > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
On Mon, Jan 06, 2003 at 12:32:43PM +0100, Peter Graf wrote: > Framebuffer implementation seems feasible, but the PDA-style > windowmanagement of picoGUI is not suitable. Apart from windowmanagement, > the picoGUI architecture seems to fit quite good. > > Is there work in progress for PicoGUI desktop-style windowmanagement, esp. > overlapping windows for multitasking applications? For the technical answers, please refer to Micah's reply. I, however, want to make some usability/HCI comments on this. It is *not* correct to refer to overlapping windows as "desktop-style" and PicoGUI's as "PDA-style". The non-overlapping mode of PicoGUI is perfectly fit for desktops, and in fact it is *better* than overlapping. Heck, I'm looking forward to (and working on) using PicoGUI as my desktop, and I will as soon as it has enough tools for me to do my work. In real-life practice, I *never* have seen anyone using overlapping windows for real work. Most people use one single "maximized" window at a time, others (when there is legitimate need to have more than one app or set of data readily available) use "tiling" (spreading the windows so that they don't overlap). Except for dialog boxes, overlapping windows are extremely confusing and unintuitive. Micah: I register my plead that even if you waste your time rewriting the engine to support overlapping, the fabulous, innovative, non-overlapping app manager remains the default. []s, |alo + -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
Hi Micah, many thanks for your very informative reply. > I'm evaluating which GUI to port to a non-unixstyle multitasking OS with > limited posix lib support. Although the CPU performance is more like > "embedded", the use is a highresolution desktop rather than a small display. If you're using too big of a display on a small CPU, things will be slow without hardware acceleration. If there's any acceleration hardware, picogui should be able to take advantage of it with the right driver. The graphics hardware is simple highcolor, linear memory mapped, non-accelerated, but has about 30 MBytes/sec bandwidth. It actually can run Linux+X at usable speed, so it should be ideal for PicoGUI+framebuffer with the native small OS. > Does this mean overlapping PicoGUI windows are only supported via X, not on > bare framebuffer without X? For now yes, but this is planned to change. Part of this is the App Manager's responsibility, and part of it is in the video driver and rendering engine. Currently PicoGUI's built-in rendering engine doesn't support overlapping correctly. However, there is a 'rootless' mode where all top-level windows are managed by an external system. This lets picogui do overlapping in X. On the framebuffer, you could do the same thing using DirectFB. PicoGUI has no DirectFB driver yet, but it wouldn't be much work to write one. There are plans to rewrite PicoGUI's rendering engine using a pretty nifty new algorithm that would make all drawing more efficient, and support full overlapping. Once this is done it would be easy to remove DirectFB if desired. I would like to avoid DirectFB, this hardware wouldn't benefit from the abstraction of graphics accelerators anyway. Frankly spoken, my problem is the decision between Nano-X (with existing acceptable window manager, but "old-fashioned" and more client resource usage) and PicoGUI (nice architecture, but very young and yet no suitable window manager.) Since FLTK is unusable on my system (lack of C++ compiler for native OS), and TinyWidgets is no more developed, I tend toward PicoGUI, because it has promising serverside widgets and themes. But as things look, I would have to wait for your new rendering engine... Can you give me a rough idea how far in the future I can hope for full overlapping windows support? Are we likely talking weeks, months, or years? Thanks, Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
On Mon, Jan 06, 2003 at 12:05:40PM -0200, Lalo Martins wrote: > On Mon, Jan 06, 2003 at 12:32:43PM +0100, Peter Graf wrote: > > Framebuffer implementation seems feasible, but the PDA-style > > windowmanagement of picoGUI is not suitable. Apart from windowmanagement, > > the picoGUI architecture seems to fit quite good. > > > > Is there work in progress for PicoGUI desktop-style windowmanagement, esp. > > overlapping windows for multitasking applications? > > For the technical answers, please refer to Micah's reply. I, however, want > to make some usability/HCI comments on this. > > It is *not* correct to refer to overlapping windows as "desktop-style" and > PicoGUI's as "PDA-style". The non-overlapping mode of PicoGUI is perfectly > fit for desktops, and in fact it is *better* than overlapping. Heck, I'm > looking forward to (and working on) using PicoGUI as my desktop, and I will > as soon as it has enough tools for me to do my work. > > In real-life practice, I *never* have seen anyone using overlapping windows > for real work. Most people use one single "maximized" window at a time, > others (when there is legitimate need to have more than one app or set of > data readily available) use "tiling" (spreading the windows so that they > don't overlap). Except for dialog boxes, overlapping windows are extremely > confusing and unintuitive. > > Micah: I register my plead that even if you waste your time rewriting the > engine to support overlapping, the fabulous, innovative, non-overlapping app > manager remains the default. :) I definitely agree that overlapping windows are terrible for usability. The current panel app manager needs improvement though. Also, someday I'll write an app manager that takes the best features of ion, the current panel manager, and blender. That would make a nice default! --Micah > > []s, >|alo >+ > -- > Those who trade freedom for security >lose both and deserve neither. > -- > http://www.laranja.org/mailto:[EMAIL PROTECTED] > pgp key: http://www.laranja.org/pessoal/pgp > > Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ > GNU: never give up freedom http://www.gnu.org/ > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
On Mon, Jan 06, 2003 at 03:16:04PM +0100, Peter Graf wrote: > Hi Micah, > > many thanks for your very informative reply. > > >> I'm evaluating which GUI to port to a non-unixstyle multitasking OS with > >> limited posix lib support. Although the CPU performance is more like > >> "embedded", the use is a highresolution desktop rather than a small > >display. > > > >If you're using too big of a display on a small CPU, things will be slow > >without hardware acceleration. If there's any acceleration hardware, > >picogui > >should be able to take advantage of it with the right driver. > > The graphics hardware is simple highcolor, linear memory mapped, > non-accelerated, > but has about 30 MBytes/sec bandwidth. It actually can run Linux+X at > usable speed, > so it should be ideal for PicoGUI+framebuffer with the native small OS. Hmm.. out of curiosity, what resolution is the display, and what CPU are you using? > > >> Does this mean overlapping PicoGUI windows are only supported via X, > >not on > >> bare framebuffer without X? > > > >For now yes, but this is planned to change. Part of this is the App > >Manager's > >responsibility, and part of it is in the video driver and rendering engine. > > > >Currently PicoGUI's built-in rendering engine doesn't support overlapping > >correctly. However, there is a 'rootless' mode where all top-level windows > >are managed by an external system. This lets picogui do overlapping in X. > >On the framebuffer, you could do the same thing using DirectFB. PicoGUI has > >no DirectFB driver yet, but it wouldn't be much work to write one. > > > >There are plans to rewrite PicoGUI's rendering engine using a pretty nifty > >new algorithm that would make all drawing more efficient, and support > >full overlapping. Once this is done it would be easy to remove DirectFB if > >desired. > > I would like to avoid DirectFB, this hardware wouldn't benefit from > the abstraction of graphics accelerators anyway. IMHO it's mainly a matter of space. DirectFB gives you direct access to the framebuffer so there's no speed penalty, and it's layering model would work nicely with picogui if you want overlapping. If you don't have acceleration you don't have to compile the drivers for acceleration. So, if you're resource constrained and DirectFB would be too big that's one thing, but it would not be a waste of space to use DirectFB. > > Frankly spoken, my problem is the decision between Nano-X (with existing > acceptable window manager, but "old-fashioned" and more client resource > usage) > and PicoGUI (nice architecture, but very young and yet no suitable window > manager.) > > Since FLTK is unusable on my system (lack of C++ compiler for native OS), > and TinyWidgets is no more developed, I tend toward PicoGUI, because it > has promising serverside widgets and themes. > But as things look, I would have to wait for your new rendering engine... > > Can you give me a rough idea how far in the future I can hope for full > overlapping windows support? Are we likely talking weeks, months, or years? Considering I haven't started it yet, and other things come up, at least months until the "S2 engine" is working. If you want overlapping windows and you can run DirectFB however, it would be little work to write a DirectFB driver for picogui and you'd get full overlapping window support. > > Thanks, > Peter > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
Lalo Martins wrote: It is *not* correct to refer to overlapping windows as "desktop-style" and PicoGUI's as "PDA-style". The non-overlapping mode of PicoGUI is perfectly fit for desktops, and in fact it is *better* than overlapping. Heck, I'm looking forward to (and working on) using PicoGUI as my desktop, and I will as soon as it has enough tools for me to do my work. In real-life practice, I *never* have seen anyone using overlapping windows for real work. Most people use one single "maximized" window at a time, others (when there is legitimate need to have more than one app or set of data readily available) use "tiling" (spreading the windows so that they don't overlap). Except for dialog boxes, overlapping windows are extremely confusing and unintuitive. Yes. It is interesting to read, that you work the same like me. Also most collegues of mine work the same way. As far as I read, this is one of the strenght of PicoGui, that it has no overlapping windows. So why go away from it. Is it not a strength, but just a shortcoming. Didn't you want to keep us away from featureism? ;-) One very fine example of a "real life" and non PDA usage of not overlapping windows is the EPOC OS, which is not only used in Psion organizers, but also in industry and on Psion notebooks. It's usage is very natural in that it does not again implement the old style desktop paradigm of a user interface, but goes back to a fullscreen on. Each person can just concentrate on one (main) applciation at a time. The application can for shure do what it want with the screen. BTW, did you ever see overlapping windows in any of the terminals you see for buying tickets, get tourist information etc.? Why should this then be good on my desktop computer? Peter, please see this as a "power" and not as a shortcoming. Also see, how happy many people still are with character mode applications. This power does not come from the restriction to characters, it comes from the the way how simple and clear they are to use. The only thing I'm not so satisfied with in PicoGUI is the kind, how the not ruinning programs are presented on the screen. These "rolled up" windows. I better would like to press a button on my keyboard and have a menu coming up, like the in windows and have the not running windows away so long. Or additional a button somewhere on the screen to click with the mouse alternatively. -- Martin Doering --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
On Mon, Jan 06, 2003 at 04:02:20PM +0100, Martin Doering wrote: > Lalo Martins wrote: > > >It is *not* correct to refer to overlapping windows as "desktop-style" and > >PicoGUI's as "PDA-style". The non-overlapping mode of PicoGUI is perfectly > >fit for desktops, and in fact it is *better* than overlapping. Heck, I'm > >looking forward to (and working on) using PicoGUI as my desktop, and I will > >as soon as it has enough tools for me to do my work. > > > >In real-life practice, I *never* have seen anyone using overlapping windows > >for real work. Most people use one single "maximized" window at a time, > >others (when there is legitimate need to have more than one app or set of > >data readily available) use "tiling" (spreading the windows so that they > >don't overlap). Except for dialog boxes, overlapping windows are extremely > >confusing and unintuitive. > > > Yes. It is interesting to read, that you work the same like me. Also > most collegues of mine work the same way. As far as I read, this is one > of the strenght of PicoGui, that it has no overlapping windows. So why > go away from it. Is it not a strength, but just a shortcoming. Didn't > you want to keep us away from featureism? ;-) Hehe, most people that know me get a good laugh out of my email signature > > One very fine example of a "real life" and non PDA usage of not > overlapping windows is the EPOC OS, which is not only used in Psion > organizers, but also in industry and on Psion notebooks. It's usage is > very natural in that it does not again implement the old style desktop > paradigm of a user interface, but goes back to a fullscreen on. Each > person can just concentrate on one (main) applciation at a time. The > application can for shure do what it want with the screen. I don't think always using fullscreen is the right idea. Even on a PDA, I get annoyed with UIs that force you to always use a fullscreen mode (read: Qtopia) > > BTW, did you ever see overlapping windows in any of the terminals you > see for buying tickets, get tourist information etc.? Why should this > then be good on my desktop computer? > > Peter, please see this as a "power" and not as a shortcoming. Also see, > how happy many people still are with character mode applications. This > power does not come from the restriction to characters, it comes from > the the way how simple and clear they are to use. > > The only thing I'm not so satisfied with in PicoGUI is the kind, how the > not ruinning programs are presented on the screen. These "rolled up" > windows. I better would like to press a button on my keyboard and have a > menu coming up, like the in windows and have the not running > windows away so long. Or additional a button somewhere on the screen to > click with the mouse alternatively. The new app manager I've been thinking of would solve this. I think there was a thread on this list a while back discussing it, but the archives are probably broke knowing sourceforge. In summary: - You can have multiple 'layouts' that would be analogous to virtual desktops or virtual terminals. They would be easy to switch between, and fullscreen - Each layout would start with one fullscreen frame. Frames could be split, merged, and resized - Each frame has a way (a pull-down menu maybe) of selecting the app that resides in it - Any app can appear in either zero or one frame in each layout - The ability to have multiple layouts and to split frames would not get in the way of a novice's ability to sit down and use an app full-screen - Everything would be accessible from a "titlebar" on the frame, a compact border or button, and/or the keyboard, depending on the device's input and display capabilities. - If you select an app for a frame that's already being displayed in another frame in the same layout, the apps would swap places I know I'd love to use a system like this :) In a typical session on my desktop, I might have one layout with only a web browser, one layout with frames displaying my email, a media player, and an IRC app, another layout with a text editor, a few terminals, and the same IRC app... > > -- > Martin Doering > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
RE: [Pgui-devel] Desktop-style window management
I also hope that there is a compile time option to turn off overlapping windows. in my applications it is not desireable to have overlapping at all except for a single "something bad happened" dialog box. -Original Message- From: Lalo Martins [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: [Pgui-devel] Desktop-style window management On Mon, Jan 06, 2003 at 12:32:43PM +0100, Peter Graf wrote: > Framebuffer implementation seems feasible, but the PDA-style > windowmanagement of picoGUI is not suitable. Apart from windowmanagement, > the picoGUI architecture seems to fit quite good. > > Is there work in progress for PicoGUI desktop-style windowmanagement, esp. > overlapping windows for multitasking applications? For the technical answers, please refer to Micah's reply. I, however, want to make some usability/HCI comments on this. It is *not* correct to refer to overlapping windows as "desktop-style" and PicoGUI's as "PDA-style". The non-overlapping mode of PicoGUI is perfectly fit for desktops, and in fact it is *better* than overlapping. Heck, I'm looking forward to (and working on) using PicoGUI as my desktop, and I will as soon as it has enough tools for me to do my work. In real-life practice, I *never* have seen anyone using overlapping windows for real work. Most people use one single "maximized" window at a time, others (when there is legitimate need to have more than one app or set of data readily available) use "tiling" (spreading the windows so that they don't overlap). Except for dialog boxes, overlapping windows are extremely confusing and unintuitive. Micah: I register my plead that even if you waste your time rewriting the engine to support overlapping, the fabulous, innovative, non-overlapping app manager remains the default. []s, |alo + -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
[Pgui-devel] List membership
Hi Everybody, Just a reminder- make sure that you are subscribed to the list from the same from the address that will appear as the From: address on outgoing mail. The list server requires me to manually approve or reject mail where this is not the case, since otherwise the list would be constantly spammed. -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
The selection of what app manager to use is available as a compile time option and a runtime option already, and it will stay that way. On Mon, Jan 06, 2003 at 08:40:48AM -0700, Gray, Tim wrote: > I also hope that there is a compile time option to turn off overlapping > windows. > > in my applications it is not desireable to have overlapping at all except > for a single "something bad happened" dialog box. > > > > -Original Message- > From: Lalo Martins [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 06, 2003 9:06 AM > To: [EMAIL PROTECTED] > Subject: Re: [Pgui-devel] Desktop-style window management > > > On Mon, Jan 06, 2003 at 12:32:43PM +0100, Peter Graf wrote: > > Framebuffer implementation seems feasible, but the PDA-style > > windowmanagement of picoGUI is not suitable. Apart from windowmanagement, > > the picoGUI architecture seems to fit quite good. > > > > Is there work in progress for PicoGUI desktop-style windowmanagement, esp. > > > overlapping windows for multitasking applications? > > For the technical answers, please refer to Micah's reply. I, however, want > to make some usability/HCI comments on this. > > It is *not* correct to refer to overlapping windows as "desktop-style" and > PicoGUI's as "PDA-style". The non-overlapping mode of PicoGUI is perfectly > fit for desktops, and in fact it is *better* than overlapping. Heck, I'm > looking forward to (and working on) using PicoGUI as my desktop, and I will > as soon as it has enough tools for me to do my work. > > In real-life practice, I *never* have seen anyone using overlapping windows > for real work. Most people use one single "maximized" window at a time, > others (when there is legitimate need to have more than one app or set of > data readily available) use "tiling" (spreading the windows so that they > don't overlap). Except for dialog boxes, overlapping windows are extremely > confusing and unintuitive. > > Micah: I register my plead that even if you waste your time rewriting the > engine to support overlapping, the fabulous, innovative, non-overlapping app > manager remains the default. > > []s, >|alo >+ > -- > Those who trade freedom for security >lose both and deserve neither. > -- > http://www.laranja.org/mailto:[EMAIL PROTECTED] > pgp key: http://www.laranja.org/pessoal/pgp > > Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ > GNU: never give up freedom http://www.gnu.org/ > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] stuff missing out of profile.helio
Micah, et al Yeah, compile a new cli_c with sockets and recompile the apps. Done. The only I've recompiled are tpcal & vrcalc. Make sure you have a line like "input = r3912ts" in your [pgserver] section of /etc/pgserver.conf, and make sure you're running the calibrator. You can have pgserver run a calibrator when necessary by setting the 'tpcal' config variable to the command to use. Since we don't yet have an app server to tell apps where to get their data files, tpcal expects its theme (calth.th) to be in the current directory. You could use something like "tpcal = cd /path/to/theme; /path/to/tpcal" to work around this. tpcal/vrcalc kept complaining about undefined symbols until I used the same libraries I used to build them. They are from TransVirtual (I think) from their defunct PocketLinux project. The recompile of tpcal creates calth.th which went into /usr/bin along with tpcal. At boot time, my pda runs the pgsession script. It cd's to /usr/bin and runs tpcal then pgserver. tpcal does not run and pgserver does not start. Here is my pgserver.conf # cat pgserver.conf [pgserver] input = r3912ts themes = /usr/lib/lcdmono.th appmgr = panel session = omnibar tpcal = "cd /usr/bin; /usr/bin/tpcal" pgserver gives the following error: pgserver_init: operating system initpgserver_init: configuration filespgserver_init: command linepgserver_init: error message tablepgserver_init: input driverspgserver_init: input filterspgserver_init: videopgserver_init: fontspgserver_init: app managerpgserver_init: networkpgserver_init: globalsInit: globals: default font Init: globals: cursor sprite bitmaps Init: globals: cursor sprite Init: globals: strings Init: globals: success pgserver_init: timerspgserver_init: initial themes*** ERROR (FILEFMT) : Theme file does not have a header! But I'm using the lcdmono.th from picogui-0.43 Any ideas? Mark _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
Hi Micah, > The graphics hardware is simple highcolor, linear memory mapped, > non-accelerated, > but has about 30 MBytes/sec bandwidth. It actually can run Linux+X at > usable speed, > so it should be ideal for PicoGUI+framebuffer with the native small OS. Hmm.. out of curiosity, what resolution is the display, and what CPU are you using? The display is maximum 1024x512 @ 64k colors. CPU is 68k (68040/68060). > I would like to avoid DirectFB, this hardware wouldn't benefit from > the abstraction of graphics accelerators anyway. IMHO it's mainly a matter of space. DirectFB gives you direct access to the framebuffer so there's no speed penalty, and it's layering model would work nicely with picogui if you want overlapping. If you don't have acceleration you don't have to compile the drivers for acceleration. So, if you're resource constrained and DirectFB would be too big that's one thing, but it would not be a waste of space to use DirectFB. I would like to avoid the additional memory usage. The strenght of the OS is that it is very small, fits into ROM, and most things run almost completely within the internal CPU caches. Also it seems much harder if two independent projects must be ported and maintained on my non-standard OS platform. Thanks a lot for your comments, Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] stuff missing out of profile.helio
On Mon, Jan 06, 2003 at 04:18:39PM +, Mark and Janice Juszczec wrote: > Micah, et al > > globalsInit: globals: default font > Init: globals: cursor sprite bitmaps > Init: globals: cursor sprite > Init: globals: strings > Init: globals: success > pgserver_init: > timerspgserver_init: > initial themes*** ERROR (FILEFMT) : Theme file does not have a header! > > > But I'm using the lcdmono.th from picogui-0.43 Is /usr/lib/lcdmono.th zero bytes? This usually happens if themec has errors. If not, it could be a mips-specific bug in the theme loader. > > Any ideas? > > Mark > > _ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] stuff missing out of profile.helio
On Mon, Jan 06, 2003 at 06:03:44PM +, Mark and Janice Juszczec wrote: > > Micah > > you wrote > > > >Is /usr/lib/lcdmono.th zero bytes? This usually happens if themec has > >errors. > > Nope. It is 2336 bytes. > > > > >If not, it could be a mips-specific bug in the theme loader. > > > > Is there a way to run pgserver with no themes? If you just don't specify any themes, widgets should appear as white boxes with black borders. > > Was the lcdmono.th in CVS or picogui-0.43.tar recreated with the new > themec? There isn't a lcdmono.th in CVS... there's a lcdmono.ths that you should be using themec to compile to lcdmono.th > > If I get brave and try to debug this, how do you suggest I start? Is the > only way to debug this on the Helio? Is there an emulator out there that > runs themes? If you think the theme itself is the problem, you can try a precompiled theme from http://picogui.org/themes/lcdmono.th If you want to run it on your desktop you just need a pgserver compiled for your desktop. If it's a mips-specific bug in pgserver, you could try and compile a gdb stub for the helio, or you could use printf()s. --Micah -- Only you can prevent creeping featurism! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
Re: [Pgui-devel] Desktop-style window management
On Mon, 6 Jan 2003, Lalo Martins wrote: :On Mon, Jan 06, 2003 at 12:32:43PM +0100, Peter Graf wrote: :In real-life practice, I *never* have seen anyone using overlapping windows :for real work. Most people use one single "maximized" window at a time, :others (when there is legitimate need to have more than one app or set of :data readily available) use "tiling" (spreading the windows so that they :don't overlap). Except for dialog boxes, overlapping windows are extremely :confusing and unintuitive. Thank you for bringing this point up - I see (when I think about it) that I DO work in a number of ways. Here are my conclusions. Just a quick note: when you work in "one window at a time", it overlaps all other windows COMPLETELY, instead of partially, which is the sense we mean when we say "overlapping". Just semantics. Within X: if an app has a number of small windows (programming environment, or image editor (gimp)), I'll have as many as will fit in tiled mode. Usually the little windows don't require scrollbars, so that they "fit" in a tiled sense. If I have a number of apps, that rely on a large amount of screen real estate, then I typically run those in overlapped mode, to reduce the chance of using up more screen real estate on unnecessary scrollbars. Basically, if a big window has a border I can grab with a mouse to bring it forward, then I'm happy for it to be under other big windows. Apps like web browsers, images, and movie players come in this class. And even if I can't see a border, I can "rely" on the app switching method of a typical window manager (Alt-Tab) to bring each window to the foreground, or use a "panel" that shows apps in a block...click on the block, brings that app forward. Within twin (160 chars by 64 lines): I typically run one window at a time, because it seems pointless to me to waste characters showing window borders when I don't need them. Running windows in a tiled sense here increases the amount of screen real estate needed to show these borders, when compared with the screen on a typical X window manager sense. Again, if the window (say, a clock) is small, then I'll stick it at the bottom of the main windows. To those of you without fixed-width fonts, I apologise ahead of time. __ |main window & text | (Underneath are a stack of other maximised | 160x60 | windows that are the same size as this one) | ...| || _ ___ |clk ||sml window | - --- The menu bar for twin only pops up when I request it (hit or ), and appears on top of any other windows, then disappears when I select something. I set it that way...to give me more real estate. So again, I suppose I mix metaphors. These are only my own responses, and probably the reason why I use X at 1280x1024 instead of 640x480 8-), and twin at 160x64 insteadof 80x25 (*yuck*) I grant that I am NOT as efficient in X as I find I am within twin, purely because I'm using the mouse when I possibly don't need to, and not using (for example) Alt-Tab instead. Hey - I'm pretty much only a home desktop-user. I will readily admit it was picogui that allowed me to see that, even though a REALLY small window was a pain, I could still use it to do IRC, for example. That's not only a testament to picogui, but also to the writers of the IRC client too. So it can be done, on certain applications, and in fact, a "one window" approach is what makes the most sense in a small-screen environment for Human Interface Useability. But, as I said, I tend to use a mixture of methods. Cheers...keep up the good work. -- /| _,.:*^*:., |\ Cheers from the Viking family, including Pippin, our cat | |_/' viking@ `\_| | |flying-brick| $FunnyMail : What do you mean, I've lost the plot? \_.caverock.net.nz_/ 5.40 : I planted them carrots right here!! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
