Re: X11 fullscreen
Russell Shaw wrote: *SNIP* You have plenty of time on your hands, don't you? This can mean only one thing: You have an idea to sell, in the hopes that people will jump on board and run with it and you won't have to do any work. I hate to disappoint you, but it doesn't work that way. David Bronaugh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
David Bronaugh wrote: Russell Shaw wrote: *SNIP* You have plenty of time on your hands, don't you? This can mean only one thing: You have an idea to sell, in the hopes that people will jump on board and run with it and you won't have to do any work. I hate to disappoint you, but it doesn't work that way. Ha, no work you say? I need no one elses work, nor do i need to sell anything. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) It's not 'hard' in the sense of being groundbreaking CS research, no, but it would take an immense amount of time to get non-Western scripts (including bidi), accessibility, copy paste, full ICCCM compliance including doing the right thing with EWMH, input (including input methods), selections, etc working properly and correctly. Oh, and your app doesn't look anything like any other app now. All that is done to a degree. Theming engine allows apps to look and act like any other system. Once you architect the full depth of the problem with minimal things that work at every stage, you can add more parallelable features whenever required. OK, sounds like it should be pretty easy for you to knock up? Ooh yeah, and your app has no concept of double-clicking. You could reimplement it and have it be completely different to the rest of the system (different maximum time between clicks, different maximum distance between click positions, etc) if you like. All the little stuff like this really does add up. Would you like a ctrl-shift+triple-middle-click popup menu? I only make useability different if i know it's the right thing to do. No, I just want double-clicking to work. Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. I didn't say it would be unconditionally easy, but to solve an immediate engineering problem of drawing to a full screen and having a menu, Xlib + OpenGL + Glut is fairly easy. I assume their requirements will eventually run deeper than 'full screen, one menu'. Progressing on from that and creating new widgets is useful innovation that can solve many more problems. No, it's not useful innovation at all. All the answers to do anything you want is available on the web, email lists, and in books. It's definitely not quick and easy to do the whole thing. No, hence why someone asking how to do something eye-wateringly simple, we should recommend they use existing toolkits. I wouldn't be recommending any of this if i found existing widget toolkits easy to make new non-trivial widgets that run well. I've battled widget toolkits since Windows95. The code for various existing X toolkits is inpenetrable, and made overly complex for porting to non-X systems that i don't require. Having thought through many problems, these codebases can be more comprehensible, but what's the use when one has had to figure out how to make a toolkit in order to figure out how to fix one? He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. pgpYiEtHHmsQd.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) - Clemens 2010/1/30 Russell Shaw rjs...@netspace.net.au: Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: This means abstracting everything with pointer indirections leading to slow Any performance problems you may have are not caused by excessive pointer dereferences. Not directly. In the context of widget kits, pointer dereferences often hide from the programmer what low level function is being called, especially when there's multiple levels. More of a pain to understand and write code knowing it will run well (sigh broken record). feature-bare toolkits. Which features are you missing from current toolkits? Foolproof multithreading. I should be able to easily have two windows being updated from different threads without interaction problems due to static vars in the toolkit. Until relatively recently, various toolkits had no kind of centralized hot-button help system that i could find. It's way too hard to make a new non-trivial widget when it should be much easier. Many widgets have performance problems when you want to scroll through 10k items from a database. I'm sure they can be made to work well with enough detailed knowledge of the widget, but to get that far, i had to figure out how widgets and everything should work because of lack of know how and documentation. Makes a toolkit rather pointless when the barrier to being productive is that high. I should be able to fork and exec from within a GUI program without problems. A gui framework baggage that comes with widgets should be minor in memory cost. Last time i was using gtk, there was no definitive way of parsing configuration files (tho there is now i think). I wanted ligatures and proper kerning in fonts. I wanted access to all the features in a truetype font file. Last i looked, pango had little documentation about using it in great or sufficient detail. Not knowing anything about non-english text, i had no hope of even knowing what to ask about pango. A simple block diagram of how it processes utf8 clusters would have gone a *long* way. Some explanation of what's in a font file and what contextual analysis is would have helped a lot. I wanted more control over hints for the window manager. That may have already existed, but there was no overview documentation in gtk about that years ago when i used it. I had to learn all the fine details of Xlib and icccm just to figure out what questions to ask. I wanted printer support. I know now that's rather vague and out of scope for widgets. There were no gtk docs explaining that. I used to be using the printer GDI in windows. There was no support for widget settings persistance, or docs saying what to do about it. If i last used a file dialog on a certain directory, i wanted it to open there next time i used the program. I know what i should do in my own way now. There was no drawing support in gtk other than gdk which i found over a year later was xlib calls. Ran slow as hell. Could use cairo now, but i stick closer to the metal and use opengl or shm images. Cairo can draw to a printer context iirc, but i'd rather just generate postscript output directly. I wanted to have accurate colour management, but i see that as out of scope of widgets now. I wanted to programmatically generate menus on the fly that adapt to the results of database retrieval based on ealier stages of the menu hierarchy. At some point gtk changed to XML files to define menus. That totally pissed me off and was when i abandoned gtk. I wanted to do window-in-window mdi. Any mention leads to howls of denial that you don't need it or it's unuseable because you can't use the app on a dual-head setup. Well, i wanted to just a drag an embedded mdi document with a mouse so that it magically becomes a top-level window. Likewise, i could drag it over the mdi container and it would become re-embedded and managed by the mdi window manager. I wanted to have a widget that acts as a window manager complete with icon handling. Then i could use a family of related applications within that shell widget, and have them all appear there in the same state next time i log on. I wanted to make independent X apps such as editors become embedded in my own widgets. I still think about that area. I wanted the whole thing to run well on a 10MHz 8-bit cpu. It still would if i omit scaleable shaded 3D buttons and do another suitable small windowing system. Memory limits for a full unicode font and various window buffers would be pushing it a bit. I still aim for that efficiency. I've read the qt book and tried qt and read the stroustrop book multiple times and know everything about C++ but remain unimpressed at the complexity
Re: X11 fullscreen
On Sun, 31 Jan 2010, Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. I don't understand your point. I think it would be great if GTK supported all the features he mentioned. (Incidentally, I think I heard someone mention that GTK3 would use the same primitives for drawing on the screen and on the printer, so that might be a step in the right direction). :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) It's not 'hard' in the sense of being groundbreaking CS research, no, but it would take an immense amount of time to get non-Western scripts (including bidi), accessibility, copy paste, full ICCCM compliance including doing the right thing with EWMH, input (including input methods), selections, etc working properly and correctly. Oh, and your app doesn't look anything like any other app now. All that is done to a degree. Theming engine allows apps to look and act like any other system. Once you architect the full depth of the problem with minimal things that work at every stage, you can add more parallelable features whenever required. OK, sounds like it should be pretty easy for you to knock up? It works, but needs refining. I shouldn't use Theming engine. That's a programmer wankword for some kind of state machine. I do theming with a simple plugin api. Ooh yeah, and your app has no concept of double-clicking. You could reimplement it and have it be completely different to the rest of the system (different maximum time between clicks, different maximum distance between click positions, etc) if you like. All the little stuff like this really does add up. Would you like a ctrl-shift+triple-middle-click popup menu? I only make useability different if i know it's the right thing to do. No, I just want double-clicking to work. It works. Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. I didn't say it would be unconditionally easy, but to solve an immediate engineering problem of drawing to a full screen and having a menu, Xlib + OpenGL + Glut is fairly easy. I assume their requirements will eventually run deeper than 'full screen, one menu'. Progressing on from that and creating new widgets is useful innovation that can solve many more problems. No, it's not useful innovation at all. Why? Try scrolling a list with 1e6 elements with ease. All the answers to do anything you want is available on the web, email lists, and in books. It's definitely not quick and easy to do the whole thing. No, hence why someone asking how to do something eye-wateringly simple, we should recommend they use existing toolkits. All the answers exist, but any low-grade resource needs searching and refining. That's why toolkits exist. All the answers in one spot. Sometimes they're not suitable answers. I wouldn't be recommending any of this if i found existing widget toolkits easy to make new non-trivial widgets that run well. I've battled widget toolkits since Windows95. The code for various existing X toolkits is inpenetrable, and made overly complex for porting to non-X systems that i don't require. Having thought through many problems, these codebases can be more comprehensible, but what's the use when one has had to figure out how to make a toolkit in order to figure out how to fix one? He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. I suggested avoiding full toolkits and use glut. The rest just got out of hand. I originally went to just use a toolkit when i wanted to make a simple cad program. That didn't get me anywhere useful. I don't suggest the usual toolkits for anything non-trivial, and that needs some amount of speed such as drawing or dragging objects with a mouse. Qt may be useable for anyone that tolerates C++. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) What do you suggest? I'd very much like to know. How do other toolkits draw widgets? I haven't bothered looking for a long time. I have found no performance problems with shm ximage for the way i use it. The results look no different to any other toolkit. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Russell Shaw wrote: Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: ... He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. I suggested avoiding full toolkits and use glut. The rest just got out of hand. I originally went to just use a toolkit when i wanted to make a simple cad program. That didn't get me anywhere useful. I don't suggest the usual toolkits for anything non-trivial, and that needs some amount of speed such as drawing or dragging objects with a mouse. Qt may be useable for anyone that tolerates C++. Cairo in gtk may be useable to a degree. I still see reports of speed problems. It is too high-level for me. It has an advantage of drawing to multiple contexts such as a printer or pdf etc. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) What do you suggest? I'd very much like to know. How do other toolkits draw widgets? I haven't bothered looking for a long time. I tried and battled XRender for some time. It was poorly documented to the point that it hardly seems like it was intended to be used by anyone generally. It also had bugs when i used it. Gtk uses it iirc, but i won't touch it now. I did read the source in X server. Glitz and other stuff wasn't a lot of use. I just use opengl if i need much acceleration. I have found no performance problems with shm ximage for the way i use it. The results look no different to any other toolkit. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: This means abstracting everything with pointer indirections leading to slow Any performance problems you may have are not caused by excessive pointer dereferences. feature-bare toolkits. Which features are you missing from current toolkits? Instead, X should have been ported to those systems and the widget toolkits should have only been a slight bit of sugar around an enhanced Xlib. If i ever do anything cross-platform, it will only be when an Xlib or an enhanced replacement of it is ported. I very much look forward to your new X toolkit: please let us know when it's available. In the meantime, let's just limit our recommendations to things that exist. pgpkSNKCrDYmD.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Sat, Jan 30, 2010 at 12:10:11PM +1100, Russell Shaw wrote: None of this really matters because i don't care if i'm the only one that uses this stuff. I'd prefer to be ignored as a troll because I have a better job than programming all day and just hack on it as a hobby for my own use. Would have been good to see existing software a bit better though. I'm now productive so i'm happy. I'm glad to hear it, but yeah, this is hugely offtopic for x...@. pgpULTMOS8zbw.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: This means abstracting everything with pointer indirections leading to slow Any performance problems you may have are not caused by excessive pointer dereferences. Not directly. In the context of widget kits, pointer dereferences often hide from the programmer what low level function is being called, especially when there's multiple levels. More of a pain to understand and write code knowing it will run well (sigh broken record). feature-bare toolkits. Which features are you missing from current toolkits? Foolproof multithreading. I should be able to easily have two windows being updated from different threads without interaction problems due to static vars in the toolkit. Until relatively recently, various toolkits had no kind of centralized hot-button help system that i could find. It's way too hard to make a new non-trivial widget when it should be much easier. Many widgets have performance problems when you want to scroll through 10k items from a database. I'm sure they can be made to work well with enough detailed knowledge of the widget, but to get that far, i had to figure out how widgets and everything should work because of lack of know how and documentation. Makes a toolkit rather pointless when the barrier to being productive is that high. I should be able to fork and exec from within a GUI program without problems. A gui framework baggage that comes with widgets should be minor in memory cost. Last time i was using gtk, there was no definitive way of parsing configuration files (tho there is now i think). I wanted ligatures and proper kerning in fonts. I wanted access to all the features in a truetype font file. Last i looked, pango had little documentation about using it in great or sufficient detail. Not knowing anything about non-english text, i had no hope of even knowing what to ask about pango. A simple block diagram of how it processes utf8 clusters would have gone a *long* way. Some explanation of what's in a font file and what contextual analysis is would have helped a lot. I wanted more control over hints for the window manager. That may have already existed, but there was no overview documentation in gtk about that years ago when i used it. I had to learn all the fine details of Xlib and icccm just to figure out what questions to ask. I wanted printer support. I know now that's rather vague and out of scope for widgets. There were no gtk docs explaining that. I used to be using the printer GDI in windows. There was no support for widget settings persistance, or docs saying what to do about it. If i last used a file dialog on a certain directory, i wanted it to open there next time i used the program. I know what i should do in my own way now. There was no drawing support in gtk other than gdk which i found over a year later was xlib calls. Ran slow as hell. Could use cairo now, but i stick closer to the metal and use opengl or shm images. Cairo can draw to a printer context iirc, but i'd rather just generate postscript output directly. I wanted to have accurate colour management, but i see that as out of scope of widgets now. I wanted to programmatically generate menus on the fly that adapt to the results of database retrieval based on ealier stages of the menu hierarchy. At some point gtk changed to XML files to define menus. That totally pissed me off and was when i abandoned gtk. I wanted to do window-in-window mdi. Any mention leads to howls of denial that you don't need it or it's unuseable because you can't use the app on a dual-head setup. Well, i wanted to just a drag an embedded mdi document with a mouse so that it magically becomes a top-level window. Likewise, i could drag it over the mdi container and it would become re-embedded and managed by the mdi window manager. I wanted to have a widget that acts as a window manager complete with icon handling. Then i could use a family of related applications within that shell widget, and have them all appear there in the same state next time i log on. I wanted to make independent X apps such as editors become embedded in my own widgets. I still think about that area. I wanted the whole thing to run well on a 10MHz 8-bit cpu. It still would if i omit scaleable shaded 3D buttons and do another suitable small windowing system. Memory limits for a full unicode font and various window buffers would be pushing it a bit. I still aim for that efficiency. I've read the qt book and tried qt and read the stroustrop book multiple times and know everything about C++ but remain unimpressed at the complexity of C++ toolkit code compared to the results achieved. I find C++ harder to understand and debug compared to C. Gdb had problems with C++. GObject was unsufficiently documented to achieve a full working knowledge of what it is doing. I might be able to figure that out now, but i still find the rest of gtk too tedious to use in C.
Re: X11 fullscreen
Le 29/01/2010 00:41, Russell Shaw a écrit : What i really meant was Forget existing widget toolkits. One can write their own that is much better than the existing ones, if you architect the thing right. Doing that is not a small job. Takes a lot of time just to think about before even writing any code. Right, so let me sum up. Dirk wants to write a full-screen app, with very little interaction with other windows. This is a trivial task for _any_ modern toolkit (gtk, qt, efl, sdl, hell even motif or swing, etc). Your suggestion to Dirk is for him to completely _ignore_ the current toolkits and to start all over from scratch, dropping 10~15 years worth of common knowledge from all the current X-based toolkits. Dirk, please try using one of the current toolkits first. And if you don't like one, try another one, don't write Xlib code directly. That's the toolkit guys' problem, it shouldn't be yours. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Le Ven 29 janvier 2010 00:53, Russell Shaw a écrit : One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) On the text processing front, hard is not relative. Working solutions are quickly being reduced to pango or qt, with pango and qt sharing components (harfbuzz) because they can't really cope alone. Modern text processing is *very* hard. English speakers usually don't realize it till they're flooded with bug reports from non-English speakers (and, probably soon, reports by English speakers, as support for advanced latin typographic features is added to pango/qt). If you want any proof, just check the OpenOffice.org bug tracker. They've not replaced their legacy text stack with pango yet, and get new text bug reports almost every day. (Not that OO.o is especially worse than other apps of the same age, but it's a heavy-duty app so people do report bugs instead of cursing privately). -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Thu, Jan 28, 2010 at 10:41:04PM +1100, Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. You should read up on Xlib and OpenGL programming. This may not be quick or easy, depending on background, but is worth it if you have ongoing use for it. If you ignore any advice this year, please make it this. And your point is? Too hard? ;) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Alan Cox wrote: One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. And how is your Gujerati and accessibility ... ? Non-existant, but the precise place and how it should be plugged in is defined for easy addition if required. I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. A lot of queries you can avoid the overhead because you can batch queries and answers. You can also stall one thread on a query while others do things. You might be waiting for one window to expose but that doesn't mean you can't be querying other stuff or rendering into other windows at the same time. I need to read the protocol book and understand it properly this time. I have found that even with XSyncronize enabled for worst possible protocol performance, a decent architecture is unaffected. With existing widget toolkits, you're floating that high in the clouds you have no chance of knowing what's happening down below in Xlib and so can't write anything efficiently. One doesn't need to be confined to Xlib drawing functions either. Just bit bang to Shm XImages. Is Xlib thread re-entrant? If not, i may do something about that. Outside of dinosaur land someone already did - its called xcb. I've used that on multiple occaisions and have found simple and required features missing. I have tried adding the missing things by adding new XML definitions. Anyway, i distinctly dislike XML anywhere i would be likely trying to make an improvement to a codebase. xcb is designed to preserve the Xlib api. I prefer to architect things completely new and efficient. If xcb running under Xlib already allows Xlib to be re-entrant, i need not worry. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Twas brillig at 23:29:43 29.01.2010 UTC+11 when rjs...@netspace.net.au did gyre and gimble: RS xcb is designed to preserve the Xlib api. I prefer to architect RS things completely new and efficient. Laughed out loud. Sorry, could not resist it. -- http://fossarchy.blogspot.com/ pgpgzhMwqp1kG.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: Glynn Clements wrote: Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. On the contrary, using bare Xlib you would be hard pressed to write even a trivial application within a month unless you're willing to give up a lot of features which many people would take for granted (e.g. configuration, support for multiple locales, interoperability with other applications, etc). As with many things, being different is automatically a loss, so you have to do better on the other aspects just to break even. One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) It's not 'hard' in the sense of being groundbreaking CS research, no, but it would take an immense amount of time to get non-Western scripts (including bidi), accessibility, copy paste, full ICCCM compliance including doing the right thing with EWMH, input (including input methods), selections, etc working properly and correctly. Oh, and your app doesn't look anything like any other app now. All that is done to a degree. Theming engine allows apps to look and act like any other system. Once you architect the full depth of the problem with minimal things that work at every stage, you can add more parallelable features whenever required. Ooh yeah, and your app has no concept of double-clicking. You could reimplement it and have it be completely different to the rest of the system (different maximum time between clicks, different maximum distance between click positions, etc) if you like. All the little stuff like this really does add up. Would you like a ctrl-shift+triple-middle-click popup menu? I only make useability different if i know it's the right thing to do. Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. I didn't say it would be unconditionally easy, but to solve an immediate engineering problem of drawing to a full screen and having a menu, Xlib + OpenGL + Glut is fairly easy. Progressing on from that and creating new widgets is useful innovation that can solve many more problems. All the answers to do anything you want is available on the web, email lists, and in books. It's definitely not quick and easy to do the whole thing. I wouldn't be recommending any of this if i found existing widget toolkits easy to make new non-trivial widgets that run well. I've battled widget toolkits since Windows95. The code for various existing X toolkits is inpenetrable, and made overly complex for porting to non-X systems that i don't require. Having thought through many problems, these codebases can be more comprehensible, but what's the use when one has had to figure out how to make a toolkit in order to figure out how to fix one? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Fri, Jan 29, 2010 at 06:34:37PM +0600, Mikhail Gusarov wrote: Twas brillig at 23:29:43 29.01.2010 UTC+11 when rjs...@netspace.net.au did gyre and gimble: RS xcb is designed to preserve the Xlib api. I prefer to architect RS things completely new and efficient. Laughed out loud. Sorry, could not resist it. Isn't that the point where people start mumbling Wayland under their breath? OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Rémi Cardona wrote: Le 29/01/2010 00:41, Russell Shaw a écrit : What i really meant was Forget existing widget toolkits. One can write their own that is much better than the existing ones, if you architect the thing right. Doing that is not a small job. Takes a lot of time just to think about before even writing any code. Right, so let me sum up. Dirk wants to write a full-screen app, with very little interaction with other windows. This is a trivial task for _any_ modern toolkit (gtk, qt, efl, sdl, hell even motif or swing, etc). Your suggestion to Dirk is for him to completely _ignore_ the current toolkits and to start all over from scratch, dropping 10~15 years worth of common knowledge from all the current X-based toolkits. Dirk, please try using one of the current toolkits first. And if you don't like one, try another one, don't write Xlib code directly. That's the toolkit guys' problem, it shouldn't be yours. One challenge: make cairo or gtk drawing full-screen run fast on any current system, or else have it tell your app that such-n-such a feature is not going to be accelerated. All i see in linux gui apps is 10 years of stagnation. And no, i will not use C++ for *anything*. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Mikhail Gusarov wrote: Twas brillig at 23:29:43 29.01.2010 UTC+11 when rjs...@netspace.net.au did gyre and gimble: RS xcb is designed to preserve the Xlib api. I prefer to architect RS things completely new and efficient. Laughed out loud. Sorry, could not resist it. I read, debug, and maintain code that is worth it. This has never included anything using Xlib. I have never wanted to do anything other than using an existing toolkit to solve engineering problems. I'm not even a programmer (tho i seem to be one now). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Le Ven 29 janvier 2010 14:40, Russell Shaw a écrit : The right way is to make each font a smart font that is simply a C library plugin. In other words, you can't handle real-world fonts. Since those cost millions and can take months or even years to create (see stix), since people like to have many of them, and want to interoperate with other people that use fonts in existing formats on other systems, I can't see how your advice is anything other than utterly wrong and dangerous. Unless someone has a few billions to blow to check if your idea is workable. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
2010/1/29 Nicolas Mailhot nicolas.mail...@laposte.net: Le Ven 29 janvier 2010 14:40, Russell Shaw a écrit : The right way is to make each font a smart font that is simply a C library plugin. In other words, you can't handle real-world fonts. Since those cost millions and can take months or even years to create (see stix), since people like to have many of them, and want to interoperate with other people that use fonts in existing formats on other systems, I can't see how your advice is anything other than utterly wrong and dangerous. Please stop feeding the troll. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Nicolas Mailhot wrote: Le Ven 29 janvier 2010 14:40, Russell Shaw a écrit : The right way is to make each font a smart font that is simply a C library plugin. In other words, you can't handle real-world fonts. Since those cost millions and can take months or even years to create (see stix), since people like to have many of them, and want to interoperate with other people that use fonts in existing formats on other systems, I can't see how your advice is anything other than utterly wrong and dangerous. Unless someone has a few billions to blow to check if your idea is workable. It's not a good solution for immediate use, but i only design things the way they should be. Many fonts may cost a bit to make, and sold at extortionistic prices over and over like any other high priced closed source licence software. They also have eulas saying no reverse engineering and no copying. I see any use of truetype/postscript fonts of questionable legality when one has to make a hinting interpreter. Many of these font files are so full of old cruft making them hard to build, verify, and modify, that i avoid them when possible for my own applications. There is no need for font creation to be expensive. It just requires a bit of artistic styling for the outlines, some simple hinting in the vertical direction (for horizontal text), and some predefined language/script specific libraries for contextual analysis. It can all be done as a C plugin making all the interpreter machinery unneccessary. There's no shortage of poor arts students that would create font outlines and have their name on it. With a decent fontforge-like font CAD program and a well defined procedure for creating a font, things would be a lot easier. I'm ok at drawing cursive font outlines on paper anyway. I'll make my own cursive font. Currently i just use font outline data copied from an existing free font for personal use. If such a new font format were released, permission from existing font authors could be sought to copy the outline data. None of this really matters because i don't care if i'm the only one that uses this stuff. I'd prefer to be ignored as a troll because I have a better job than programming all day and just hack on it as a hobby for my own use. Would have been good to see existing software a bit better though. I'm now productive so i'm happy. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
I just want to draw some stuff on screen, probably using cairo, but I want this not in a window, but on the full screen. Kind regards, Dirk John Tapsell wrote: 2010/1/28 Dirk De Becker dirk.debec...@dzine.be: Hi all, I want to make an application in C/C++ that draws fullscreen stuff on an X11 server. Can anyone tell me how to do this? What are you trying to do exactly? What does your program do? John attachment: Dirk_DeBecker.vcf___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
2010/1/28 Dirk De Becker dirk.debec...@dzine.be: Hi all, I want to make an application in C/C++ that draws fullscreen stuff on an X11 server. Can anyone tell me how to do this? What are you trying to do exactly? What does your program do? John ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
2010/1/28 Dirk De Becker dirk.debec...@dzine.be: I just want to draw some stuff on screen, probably using cairo, but I want this not in a window, but on the full screen. That gives me zero new information. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Presently, I am using gtk to create a drawable surface for cairo to draw on, but I am wondering whether or not gtk is slowing the drawing down a lot. Therefor, I was wondering whether it is possible to do some drawing with cairo, but not using gtk windows. However, I would preferably have my drawable surface to be full screen (i.e. without borders). I hope this is more informative. Thanks a lot for you swift responses. Dirk John Tapsell wrote: 2010/1/28 Dirk De Becker dirk.debec...@dzine.be: I just want to draw some stuff on screen, probably using cairo, but I want this not in a window, but on the full screen. That gives me zero new information. attachment: Dirk_DeBecker.vcf___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Tom, Thanks for the clarifying questions, since I had no clue what information John needs. The answers: - I want my program to be dominating the entire display (i.e. to be on top of all other graphics). Maybe later on, I will like to be able to switch between being inside a window and being on top of everything else, but for now, being on top of everything else will do just fine. - At present, I will not be changing the resolution (again, this will probably be added in the future). - I will not do 3D stuff, videos might be possible. Dirk Tom Cowell wrote: Dirk (I expect) John has a spectrum of possible answers in mind, but many of them are wrong for your needs, and it would take him a long time to write them all down. Maybe you can help him pick the right answer by providing information like: Do you plan for other programs to be using the display? Is it OK for them to appear on top of your stuff, or do you want your stuff to completely dominate the display? Do you want to change the resolution when your program runs? Are you planning to do 3D stuff, or video? Cheers Tom On 28 January 2010 11:36, John Tapsell johnf...@gmail.com wrote: 2010/1/28 Dirk De Becker dirk.debec...@dzine.be: I just want to draw some stuff on screen, probably using cairo, but I want this not in a window, but on the full screen. That gives me zero new information. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg attachment: Dirk_DeBecker.vcf___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Thu, 2010-01-28 at 11:51 +0100, Dirk De Becker wrote: Thanks for the clarifying questions, since I had no clue what information John needs. The answers: - I want my program to be dominating the entire display (i.e. to be on top of all other graphics). Maybe later on, I will like to be able to switch between being inside a window and being on top of everything else, but for now, being on top of everything else will do just fine. - At present, I will not be changing the resolution (again, this will probably be added in the future). - I will not do 3D stuff, videos might be possible. You want gtk_window_fullsceen() then. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Dirk De Becker wrote: Tom, Thanks for the clarifying questions, since I had no clue what information John needs. The answers: - I want my program to be dominating the entire display (i.e. to be on top of all other graphics). Maybe later on, I will like to be able to switch between being inside a window and being on top of everything else, but for now, being on top of everything else will do just fine. - At present, I will not be changing the resolution (again, this will probably be added in the future). - I will not do 3D stuff, videos might be possible. To cover the whole screen, use the _NET_WM_STATE_FULLSCREEN state to maximize your X window. http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551694 To have unlimited power in 2D and 3D drawing, use openGL direct with Xlib: http://www.sv.vt.edu/classes/opengl/examples/porting/glxsimple.c Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. You should read up on Xlib and OpenGL programming. This may not be quick or easy, depending on background, but is worth it if you have ongoing use for it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Russell Shaw rjs...@netspace.net.au writes: Dirk De Becker wrote: Tom, Thanks for the clarifying questions, since I had no clue what information John needs. The answers: - I want my program to be dominating the entire display (i.e. to be on top of all other graphics). Maybe later on, I will like to be able to switch between being inside a window and being on top of everything else, but for now, being on top of everything else will do just fine. - At present, I will not be changing the resolution (again, this will probably be added in the future). - I will not do 3D stuff, videos might be possible. To cover the whole screen, use the _NET_WM_STATE_FULLSCREEN state to maximize your X window. http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551694 To have unlimited power in 2D and 3D drawing, use openGL direct with Xlib: http://www.sv.vt.edu/classes/opengl/examples/porting/glxsimple.c Wow, a Mark Kilgard example that doesn't use GLUT :) (Of course, it is using an old, outdated OpenGL version.) Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. I think opinions are somewhat divided on that point. A good toolkit lets you do pretty much anything you want with much less work, and no significant performance cost. (Frequently with higher performance, as someone has probably spent a fair bit of effort investigating how to get optimal performance out of the underlying system.) A good toolkit will also often do the right thing on other people's computers, whereas your own code tends to work correctly only on your own computer. (One of the basic rules of programming: If it isn't tested, it doesn't work.) And it will typically be updated to take advantage of new features in the future, making your program still work and sometimes work better. The main problem (as with all abstractions) is that if you know exactly what you want to do in the low-level layer (e.g. X11), it can be very hard to figure out how to do that from higher up. And it can take some time for interesting new features to be supported. (That being said, I tend to favour using X11 and OpenGL directly myself...) eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. Unless you need to get any real work done - like non western font rendering, accessibility (to make your app meet legal requirements in parts of the world etc) I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) (or use Xcb if you aren't quite so serious) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. On the contrary, using bare Xlib you would be hard pressed to write even a trivial application within a month unless you're willing to give up a lot of features which many people would take for granted (e.g. configuration, support for multiple locales, interoperability with other applications, etc). As with many things, being different is automatically a loss, so you have to do better on the other aspects just to break even. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Thu, 28 Jan 2010 11:51:14 +0100 Dirk De Becker dirk.debec...@dzine.be wrote: Tom, Thanks for the clarifying questions, since I had no clue what information John needs. The answers: - I want my program to be dominating the entire display (i.e. to be on top of all other graphics). Maybe later on, I will like to be able to switch between being inside a window and being on top of everything else, but for now, being on top of everything else will do just fine. - At present, I will not be changing the resolution (again, this will probably be added in the future). - I will not do 3D stuff, videos might be possible. Maybe SDL (http://www.libsdl.org/) is for you. You can do fullscreen and windowed mode, it is supported by cairo and you can do video (and 3D too). harry signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Alan Cox wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. Unless you need to get any real work done - like non western font rendering, accessibility (to make your app meet legal requirements in parts of the world etc) One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. Is Xlib thread re-entrant? If not, i may do something about that. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Glynn Clements wrote: Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. On the contrary, using bare Xlib you would be hard pressed to write even a trivial application within a month unless you're willing to give up a lot of features which many people would take for granted (e.g. configuration, support for multiple locales, interoperability with other applications, etc). As with many things, being different is automatically a loss, so you have to do better on the other aspects just to break even. One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Alan Cox wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. Unless you need to get any real work done - like non western font rendering, accessibility (to make your app meet legal requirements in parts of the world etc) One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. One doesn't need to be confined to Xlib drawing functions either. Just bit bang to Shm XImages. Is Xlib thread re-entrant? If not, i may do something about that. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Thu, Jan 28, 2010 at 10:41:04PM +1100, Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. You should read up on Xlib and OpenGL programming. This may not be quick or easy, depending on background, but is worth it if you have ongoing use for it. If you ignore any advice this year, please make it this. Cheers, Daniel pgpQXuOJqUouz.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. And how is your Gujerati and accessibility ... ? I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. A lot of queries you can avoid the overhead because you can batch queries and answers. You can also stall one thread on a query while others do things. You might be waiting for one window to expose but that doesn't mean you can't be querying other stuff or rendering into other windows at the same time. One doesn't need to be confined to Xlib drawing functions either. Just bit bang to Shm XImages. Is Xlib thread re-entrant? If not, i may do something about that. Outside of dinosaur land someone already did - its called xcb. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: Glynn Clements wrote: Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. On the contrary, using bare Xlib you would be hard pressed to write even a trivial application within a month unless you're willing to give up a lot of features which many people would take for granted (e.g. configuration, support for multiple locales, interoperability with other applications, etc). As with many things, being different is automatically a loss, so you have to do better on the other aspects just to break even. One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) It's not 'hard' in the sense of being groundbreaking CS research, no, but it would take an immense amount of time to get non-Western scripts (including bidi), accessibility, copy paste, full ICCCM compliance including doing the right thing with EWMH, input (including input methods), selections, etc working properly and correctly. Oh, and your app doesn't look anything like any other app now. Ooh yeah, and your app has no concept of double-clicking. You could reimplement it and have it be completely different to the rest of the system (different maximum time between clicks, different maximum distance between click positions, etc) if you like. All the little stuff like this really does add up. Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. pgp1Byu0LdKil.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
2010/1/29 Daniel Stone dan...@fooishbar.org: Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. Not to mention that people are starting to demand cross-platform apps. John ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Harald Braumann wrote: Maybe SDL (http://www.libsdl.org/) is for you. You can do fullscreen and windowed mode, it is supported by cairo and you can do video (and 3D too). harry Thanks Harry, I will look into this. Dirk attachment: Dirk_DeBecker.vcf___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
