From: Ian S. <ian...@st...> - 2010-01-04 10:11:58
|
Yu, I am afraid that this is not a substantive reply. First, please can you post in raw text (see the vxl-users list policy at http://vxl.sourceforge.net/vxl-users-policy.html ) Secondly you may experience some delay in receiving a useful reply to this and your last message, since many of us are on holiday at the moment. Ian. > I am considering the possibility of adding more dialog widgets to VGUI without changing the code of vgui_dialog, vgui_dialog_impl, and its concrete implementations. The classes vgui_dialog_extensions and vgui_dialog_extensions_impl provide one way to do that. That is, adding widgets that are not supported by vgui_dialog into vgui_dialog_extensions. From the viewpoint of component design, there is no problem with this approach: vgui_dialog_extensions is a vgui_dialog and vgui_dialog_extensions_impl is a vgui_dialog_imp. This fits well with C++ public inheritance. However, the problem arises from the concrete implementation of vgui_dialog_extensions_impl. Let’s call it vgui_foo_dialog_extensions_impl when the toolkit foo is used. > For now, the class hierarchy looks like this: > vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl > /|\ /|\ > | | > vgui_dialog_extensions vgui_dialog_extensions_impl vgui_foo_dialog_extensions_impl > where the arrow pointing from the child to parent represents public inheritance. > So how to define vgui_foo_dialog_extensions_impl? > One way is define it as subclass of vgui_dialog_extensions_impl: > vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl > /|\ /|\ > | | > vgui_dialog_extensions vgui_dialog_extensions_impl <-- vgui_foo_dialog_extensions_impl > A drawback of this approach is that vgui_foo_dialog_extensions_impl has to duplicate all the code of vgui_foo_dialog_impl. This is exactly what vgui_mfc_dialog_extensions_impl does. > To enhance code reuse, the method below is better > vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl > /|\ /|\ /|\ > | | | > vgui_dialog_extensions vgui_dialog_extensions_impl <-- vgui_foo_dialog_extensions_impl > In this multiple inheritance relation, however, we have to use virtual inheritance to insure members of vgui_dialog_impl are not ambiguous. This also implies we have to modify all the classes that need virtual inheritance. > A critical problem of both methods is that given a pointer to vgui_dialog_impl, how can we tell whether it’s a vgui_foo_dialog_impl*, or vgui_foo_dialog_extensions_impl* without RTTI? > Given the analysis above, it seems that modifying existent VGUI code is inevitable and extending vgui_dialog and vgui_dialog_impl directly is better than introducing vgui_dialog_extensions and vgui_dialog_extensions_impl. > I’d like to know your suggestions on this issue, thanks. > > Lianqing Yu > 2010-1-1 |
From: Gamze T. <gdt...@ya...> - 2010-01-04 21:08:41
|
Hi, I implemented those extensions classes to work around some implementation issues like: regular vgui_dialog and vgui_dialog_impl classes does not give you the flexibility to arrange the items on the dialog. Each item is placed as a separate line in the dialog, considering dialogs only consists of several items. We came across a need to generate big dialogs with many fields and to group some of the fields together in one line. So, I override the dialog implementation by adding line breaks, and directory browsers (where you can only select files in vgui) etc. So these extension classes are not necessarily part of vgui_dialog and not everybody needed to inherit from them for each different platform. You just need to work with vgui_dialog and vgui_dialog_impl classes for the most of the time. You do not need to inherit from vgui_dialog_extensions if you do not have dialog needs like ours ( I thought that would mainly interest our project). Maybe the naming confuse people, the right naming would be something like: vgui_another_dialog. Hope this helps. Maybe we need to modify vgui_dialog to include these additional functionalities like arrangement of fields etc. if there is a consensus on that. Gamze Tunali LEMS Brown University ------------------------------------------------------------------------ I am considering the possibility of adding more dialog widgets to VGUI without changing the code of vgui_dialog, vgui_dialog_impl, and its concrete implementations. The classes vgui_dialog_extensions and vgui_dialog_extensions_impl provide one way to do that. That is, adding widgets that are not supported by vgui_dialog into vgui_dialog_extensions. From the viewpoint of component design, there is no problem with this approach: vgui_dialog_extensions is a vgui_dialog and vgui_dialog_extensions_impl is a vgui_dialog_imp. This fits well with C++ public inheritance. However, the problem arises from the concrete implementation of vgui_dialog_extensions_impl. Let’s call it vgui_foo_dialog_extensions_impl when the toolkit foo is used. For now, the class hierarchy looks like this: vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl /|\ /|\ | | vgui_dialog_extensions vgui_dialog_extensions_impl vgui_foo_dialog_extensions_impl where the arrow pointing from the child to parent represents public inheritance. So how to define vgui_foo_dialog_extensions_impl? One way is define it as subclass of vgui_dialog_extensions_impl: vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl /|\ /|\ | | vgui_dialog_extensions vgui_dialog_extensions_impl <-- vgui_foo_dialog_extensions_impl A drawback of this approach is that vgui_foo_dialog_extensions_impl has to duplicate all the code of vgui_foo_dialog_impl. This is exactly what vgui_mfc_dialog_extensions_impl does. To enhance code reuse, the method below is better vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl /|\ /|\ /|\ | | | vgui_dialog_extensions vgui_dialog_extensions_impl <-- vgui_foo_dialog_extensions_impl In this multiple inheritance relation, however, we have to use virtual inheritance to insure members of vgui_dialog_impl are not ambiguous. This also implies we have to modify all the classes that need virtual inheritance. A critical problem of both methods is that given a pointer to vgui_dialog_impl, how can we tell whether it’s a vgui_foo_dialog_impl*, or vgui_foo_dialog_extensions_impl* without RTTI? Given the analysis above, it seems that modifying existent VGUI code is inevitable and extending vgui_dialog and vgui_dialog_impl directly is better than introducing vgui_dialog_extensions and vgui_dialog_extensions_impl. I’d like to know your suggestions on this issue, thanks. Lianqing Yu 2010-1-1 |
From: YuLianqing <yu...@li...> - 2010-01-06 15:32:08
|
Hi Gamze, Thanks for your opinion. I think the arrangement of dialog fields is an important feature and line_break is one of such examples. I have two constructive suggestions about vgui dialog. First is the design of class relation mentioned on my first email. I favour to put all necessary features (format descriptors, widgets etc.) into one class (i.e. vgui_dialog and vgui_dialog_impl) for three reasons. First, if there is a long chain of class inheritance rooted from vgui_dialog, users may get confused about this relation and have difficulty in choosing the correct one, vgui_this_dialog or vgui_that_dialog? Second, the introduction of the toolkit implementation makes it difficult to identify the actual class type for a pointer to vgui_dialog. Is it a *vgui_foo_dialog_impl or a *vgui_foo_dialog_extenstions_impl? Third, to encourage code reuse, vgui_foo_dialog_extenstions_impl should inherit from both vgui_foo_dialog_impl and vgui_dialog_extensions_impl. This multiple inheritance is awkward for some virtual member functions such as ask. The second issue is the addition of some common widgets (push button, radio button, spin, progress bar, list view, tree view). We have implemented some of them in our private vgui-based applications and like to contribute the code. I believe the introduction of these decades-old widgets won't make vgui commercial oriented. I would like to more opinions from vxl developers and users about these two issues. Thanks. Lianqing Yu 2010-1-6 > Date: Mon, 4 Jan 2010 13:08:34 -0800 > From: gdt...@ya... > To: vxl...@li... > CC: vj...@le...; mu...@le... > Subject: Re: [Vxl-users] A design issue about extending vgui_dialog > > Hi, > > I implemented those extensions classes to work around some implementation issues like: > > regular vgui_dialog and vgui_dialog_impl classes does not give you the flexibility to arrange the items on the dialog. Each item is placed as a separate line in the dialog, considering dialogs only consists of several items. We came across a need to generate big dialogs with many fields and to group some of the fields together in one line. So, I override the dialog implementation by adding line breaks, and directory browsers (where you can only select files in vgui) etc. So these extension classes are not necessarily part of vgui_dialog and not everybody needed to inherit from them for each different platform. You just need to work with vgui_dialog and vgui_dialog_impl classes for the most of the time. You do not need to inherit from vgui_dialog_extensions if you do not have dialog needs like ours ( I thought that would mainly interest our project). Maybe the naming confuse people, the right naming would be something like: vgui_another_dialog. > > Hope this helps. Maybe we need to modify vgui_dialog to include these additional functionalities like arrangement of fields etc. if there is a consensus on that. > > Gamze Tunali > LEMS > Brown University > > ------------------------------------------------------------------------ > I am considering the possibility of adding more dialog widgets to VGUI without changing the code of vgui_dialog, vgui_dialog_impl, and its concrete implementations. The classes vgui_dialog_extensions and vgui_dialog_extensions_impl provide one way to do that. That is, adding widgets that are not supported by vgui_dialog into vgui_dialog_extensions. From the viewpoint of component design, there is no problem with this approach: vgui_dialog_extensions is a vgui_dialog and vgui_dialog_extensions_impl is a vgui_dialog_imp. This fits well with C++ public inheritance. However, the problem arises from the concrete implementation of vgui_dialog_extensions_impl. Let’s call it vgui_foo_dialog_extensions_impl when the toolkit foo is used. > For now, the class hierarchy looks like this: > vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl > /|\ /|\ > | | > vgui_dialog_extensions vgui_dialog_extensions_impl vgui_foo_dialog_extensions_impl > where the arrow pointing from the child to parent represents public inheritance. > So how to define vgui_foo_dialog_extensions_impl? > One way is define it as subclass of vgui_dialog_extensions_impl: > vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl > /|\ /|\ > | | > vgui_dialog_extensions vgui_dialog_extensions_impl <-- vgui_foo_dialog_extensions_impl > A drawback of this approach is that vgui_foo_dialog_extensions_impl has to duplicate all the code of vgui_foo_dialog_impl. This is exactly what vgui_mfc_dialog_extensions_impl does. > To enhance code reuse, the method below is better > vgui_dialog vgui_dialog_impl <-- vgui_foo_dialog_impl > /|\ /|\ /|\ > | | | > vgui_dialog_extensions vgui_dialog_extensions_impl <-- vgui_foo_dialog_extensions_impl > In this multiple inheritance relation, however, we have to use virtual inheritance to insure members of vgui_dialog_impl are not ambiguous. This also implies we have to modify all the classes that need virtual inheritance. > A critical problem of both methods is that given a pointer to vgui_dialog_impl, how can we tell whether it’s a vgui_foo_dialog_impl*, or vgui_foo_dialog_extensions_impl* without RTTI? > Given the analysis above, it seems that modifying existent VGUI code is inevitable and extending vgui_dialog and vgui_dialog_impl directly is better than introducing vgui_dialog_extensions and vgui_dialog_extensions_impl. > I’d like to know your suggestions on this issue, thanks. > > Lianqing Yu > 2010-1-1 > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users _________________________________________________________________ 约会说不清地方?来试试微软地图最新msn互动功能! http://ditu.live.com/?form=TL&swm=1 |