Do you know how to handle accessibility problems if we're using non-standard gtk+ widgets? For people who are blind, custom widgets might not work. I didn't notice this until the developer of Knoppix mentioned it. Personally I think this issue is quite important but I don't have time to investigate ATK yet. All built-in GtkWidgets have ATK support, but with custom ones, we may need to do the work ourselves. Any suggestions?
If you're doing a button widget now, please considering adding an option to make the icon look sunken when being pressed. This used to work in old lxpanel and was requested for many times by our users. The direction to draw with cairo and pango is quite correct and I totally agree. I want to do that, too. This makes things much easier and cleaner. On Thu, Mar 18, 2010 at 8:01 AM, Marty Jack <[email protected]> wrote: > The reason to have a custom widget is to throw away hundreds and hundreds of > lines of code that try to make the standard widgets perform properly. I have > a year of experience trying to get the background draw and other things to > work successfully. It is extremely difficult in the systray, and is now done > with a brute force recursive walk over the entire widget tree. I have over > thirty years experience writing all kinds of system software for one of the > better known computer manufacturers, so I am able to draw on plenty of > experience to make what I think are sensible design choices. > > With my system, the entire panel is a GtkWindow that contains a GtkBox that > then contains LXButtons, LXGrids containing LXButtons or GtkSockets or > GtkDrawingAreas (CPU and Pager). Period. And it is all arranged so that the > only widget that needs to draw the background choice is the top level > GtkWindow (and the sockets need some special handling). Furthermore, the > main drawing flow paths are all direct Cairo and Pango, so it is about as > efficient as you can get, given you are staying within GTK. > > The amount of code that it takes to have an LXButton look just like a > GtkButton when you want it to is 20 lines. > > I will make three other observations: > > Someone who was critical of me for not writing icon grids as a widget the > first time should take a look at the way they left prelight done from the > outside in fb_button_enter and friends. That takes about 30 lines of code in > the LXButton. > > I tend to agree that the na-tray-manager is good. They have spent a lot of > energy making it work nicely, especially on ARGB visuals. You can tell from > reading the code, and especially in the spot where they synthesize an Expose > event on the plug, that they had a lot of trouble getting it working. > > The half finished grid in tray2 will not be serviceable in Arabic speaking > areas. > > On 03/17/2010 05:54 PM, Shae Smittle wrote: >> PCMan: >> >>>The artwork thing is quite subjective so no single man can decide >>>which one is better for the whole community. >>>Before we replace the default theme with another one, I hope there can >>>be a popularity contest or something similar on the forum. >> >> Maybe you misunderstood what I was going for with my discussion of the >> theme. I had two points to make really: >> >> 1) LXDE is probably in need of a new, fresh theme; the perfect time to >> implement such a theme is when pcmanfm2 becomes the default fm/desktop >> program because we could get all of our breaking overwith in one fatal >> swoop. >> >> 2) I have created a possible theme that could be used and it >> is available at the forum for trying it out and further discussion. >> >>>1. In the past, those icon cannot be resized, and this makes things >>>ugly when the panel size is changed. That's not an issue before >>>because the panel size cannot be changed on the fly. >>>2. Later, when user preferences dialog gets improved, it's possible to >>>change the panel size on the fly, so apparently icon sizes should be >>>updated along with panel size. So I tried to resize the icons >>>according to the height of panels. >>>3. Then, Marty Jack joined us, and try to implement grid layout. So >>>now we can have multiple rows of icons. Then a fixed icon size is >>>preferred again. That's why there is a config value for icon size now. >>> >>>So, for historical reasons, that part became a little bit scary. >>>Rather than patches, I think we need to rethink the design and do a >>>rewrite for that part after a consensus of how should it work is made. >>>That's why I haven't check in your patch. Another reason is, the >>>deadline for Lubuntu release is approaching and I need to finish this >>>one in time so I'm focusing on it recenlty. Otherwise Lubuntu users >>>will get a broken file manager. After the file manager is released, >>>I'll come back and work on other parts. >> >> Concerning the code of lxpanel taskbar, I got the feeling that something >> like that happened. My primary goal with this is to spark this kind of >> discussion about what the proper behavior is. >> >> I think pcmanfm2 is going great! The only problem I have had is with >> compressing/uncompressing via right-click context menu. Keep up the >> amazing work; you set a great example. >> >>>Yes you're right we need a screenshot tool! A simple and clean one >>>written in C or vala. >>>If you're willing to do this part that will be great! >> >> Thanks for mentioning Vala, I might try that language out as I have been >> wanting to for a while. (As I have mostly used C and Java before.) >> >> Marty Jack: >> I understand what you are saying, but I will tell you why I disagree. >> If you set the panel size to 28 for 24 pixel icons, you just create >> more wasted space, as the icons outside of the taskbar are 4 short of >> the entire panel. It seems the approach in gnome is to have the taskbar >> use size 16 icons. the problem is that either you have wasted space >> outside the taskbar OR you clip the taskbar buttons. Either is a >> problem so clearly something should be done to fix the situation. >> >> It is great that you are working on those things, but personally I do >> not see the point of a "Button Widget." I would personally be >> very disappointed if that button widget did not use GTK buttons. >> >> I do not quite understand your statement about non-flat buttons. I >> personally suspect that people use non-flat buttons because they look >> like proper buttons and not just a word on a panel. Composited world or >> not, I suspect that eliminating non-flat GTK buttons would be a mistake. >> >> Shae Smittle >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lxde-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxde-list > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
