Home » Archived » Visual Editor (VE) » Comparing to other GUI tool
| Comparing to other GUI tool [message #67120] |
Fri, 15 October 2004 08:40  |
Eclipse User |
|
|
|
I really would like to work with VE, but there are still a number of
troubles related to hand coding that I can't live with.
Compared to Jigloo (http://cloudgarden.com/jigloo/), VE is still very
slow on linux and its code parser isn't much tolerant, in other words,
the code have to look THAT way to be parsed.
On this matter, Jigloo offers much more flexibility. The other VE
features are OK in my opinion.
So, I have no alternative except wait the next versions before I can use
VE in a production environment in linux.
Anyway, thanks for the great work, guys.
iran
|
|
|
| Re: Comparing to other GUI tool [message #67140 is a reply to message #67120] |
Fri, 15 October 2004 11:31  |
| Eclipse User |
|
|
|
Originally posted by: joerg.von.frantzius.artnology.nospam.com
Hi Iran,
you might want to try www.swt-designer.com which also supports JFace
components such as TreeViewer and TableViewer. Telling from a quick
look, Jigloo doesn't seem to support that, and neither does VE currently
(it's on their plan, though).
Iran schrieb:
> I really would like to work with VE, but there are still a number of
> troubles related to hand coding that I can't live with.
>
> Compared to Jigloo (http://cloudgarden.com/jigloo/), VE is still very
> slow on linux and its code parser isn't much tolerant, in other words,
> the code have to look THAT way to be parsed.
>
> On this matter, Jigloo offers much more flexibility. The other VE
> features are OK in my opinion.
>
> So, I have no alternative except wait the next versions before I can
> use VE in a production environment in linux.
>
> Anyway, thanks for the great work, guys.
>
> iran
|
|
|
| Re: Comparing to other GUI tool [message #67190 is a reply to message #67120] |
Fri, 15 October 2004 14:44 |
| Eclipse User |
|
|
|
Iran wrote:
> I really would like to work with VE, but there are still a number of
> troubles related to hand coding that I can't live with.
>
> Compared to Jigloo (http://cloudgarden.com/jigloo/), VE is still very
> slow on linux
I agree that Linux speed could be better. That's true of Eclipse in
general on Linux, but it's very hard to pin down exactly where the hot
spots are. We welcome any and all help here.
One way you can help us is to describe exactly the operations that are
too slow on Linux. For example, "dropping a control is pretty quick for
me on Linux, but typing code in the editor can take a Looooong time
before the status bar says 'synchronized' again." Or whatever it is for
you.
> and its code parser isn't much tolerant, in other words,
> the code have to look THAT way to be parsed.
Can you be more specific? What coding patterns do we not support that
you'd like to see? We're right now in the middle of working on the VE
1.1 draft plan and any feedback you can give us right now is extremely
valuable.
> On this matter, Jigloo offers much more flexibility. The other VE
> features are OK in my opinion.
>
> So, I have no alternative except wait the next versions before I can use
> VE in a production environment in linux.
Thanks for your feedback. We're working hard to make VE better and I
hope that soon it will live up to your expectations. Please help us
ensure that this happens.
Best regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Comparing to other GUI tool [message #67320 is a reply to message #67190] |
Mon, 18 October 2004 09:16 |
| Eclipse User |
|
|
|
Ok. I hope I can help with my comments:
> I agree that Linux speed could be better. That's true of Eclipse in
> general on Linux, but it's very hard to pin down exactly where the hot
> spots are. We welcome any and all help here.
I'm ok with Eclipse speed in Linux (I accepted it, :). My comment about
VE speed was when it's compared to Jigloo (take a look on it and you
will know what I mean). It's related to the time VE takes to render the
form when I generate components typing in the editor (it's my prefered
way to work. I'm paranoid about code organization).
>
>> and its code parser isn't much tolerant, in other words, the code have
>> to look THAT way to be parsed.
>
>
> Can you be more specific? What coding patterns do we not support that
> you'd like to see? We're right now in the middle of working on the VE
> 1.1 draft plan and any feedback you can give us right now is extremely
> valuable.
Take this code:
public VETest(JDialog owner) {
super(owner, "Dialog title", true);
initialize();
}
private void initialize() {
this.setSize(400, 300);
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE) ;
this.setContentPane(getContent());
}
VE shows a warning like WindowConstants.EXIT_ON_CLOSE is too complicated
to be evaluated". So I have to use
"javax.swing.WindowConstants.EXIT_ON_CLOSE", which is unecessary if I
have the "import".
In this example too, after changing the constructor, the first
modification I do in code causes VE to freeze eclipse.
But in later tests, seems like when "blablabla is too complicated to be
evaluated" is shown, a few seconds later VE freezes. So I'm not sure
about it.
In this simple example, sometimes VE takes 7 seconds to render the view.
>
>> On this matter, Jigloo offers much more flexibility. The other VE
>> features are OK in my opinion.
>>
>> So, I have no alternative except wait the next versions before I can
>> use VE in a production environment in linux.
>
>
> Thanks for your feedback. We're working hard to make VE better and I
> hope that soon it will live up to your expectations. Please help us
> ensure that this happens.
By the way, I would like to make a few sugestions:
- minimize the use of qualified names, or at least let the developer
choose the way he wants. In my opinion, use of imports let the code
easier to read.
- let the developer choose if he wants to see the "preview" window (that
separate window)
- make easier access to grid options (show, configure, etc)
Thanks and best regards.
iran
|
|
|
| Re: Comparing to other GUI tool [message #67421 is a reply to message #67320] |
Mon, 18 October 2004 14:01 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Iran wrote:
>
>
> Take this code:
>
> public VETest(JDialog owner) {
> super(owner, "Dialog title", true);
> initialize();
> }
>
> private void initialize() {
> this.setSize(400, 300);
> this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE) ;
> this.setContentPane(getContent());
> }
>
> VE shows a warning like WindowConstants.EXIT_ON_CLOSE is too complicated
> to be evaluated". So I have to use
> "javax.swing.WindowConstants.EXIT_ON_CLOSE", which is unecessary if I
> have the "import".
This particular problem was fixed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=69675 and will be available soon on a
service stream build. This fix resolve many other problems (see the dups).
>
> In this example too, after changing the constructor, the first
> modification I do in code causes VE to freeze eclipse.
>
> But in later tests, seems like when "blablabla is too complicated to be
> evaluated" is shown, a few seconds later VE freezes. So I'm not sure
> about it.
>
Open a bugzilla with a step by step instructions to recreate this... this is a bug and we need
to address this
> In this simple example, sometimes VE takes 7 seconds to render the view.
are you referring to the code above? Performance is something we really need to focus... but it will
help to focus on particular use cases.
Is this 7sec. on a first time (cold) open? change in the source?
|
|
| |
| Re: Comparing to other GUI tool [message #67724 is a reply to message #67625] |
Tue, 19 October 2004 12:37 |
| Eclipse User |
|
|
|
Originally posted by: mendelgili.netscape.net
Iran wrote:
> Thanks for your help.
>
>>
>> Open a bugzilla with a step by step instructions to recreate this...
>> this is a bug and we need
>> to address this
>
>
> How do I do this? I'm a newbie in this matter.
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=VE
>
>> are you referring to the code above? Performance is something we
>> really need to focus... but it will
>> help to focus on particular use cases.
>> Is this 7sec. on a first time (cold) open? change in the source?
>
>
> Not just the code above, but any code. It's just a simple one, but in
> complex forms this time can increase significantly. This happens in both
> situations: when opening editor and after changes in the source.
>
The first time around (cold) start, VE (currently) spends significant amount of time loading classes, introspecting
etc... sometimes it seems as if VE is touching everything on the spindle... we will have to get better at this.
The second time around VE should be much much faster... (warm) open an empty file, is instantaneous in v1.z, and clearly
the more components you have the longer it will take. 7sec. is a long time for a medium (worm start) file. We do
intend to focus more on performance than we did in v1.x.
|
|
|
| Re: Comparing to other GUI tool [message #601654 is a reply to message #67120] |
Fri, 15 October 2004 11:31 |
| Eclipse User |
|
|
|
Originally posted by: joerg.von.frantzius.artnology.nospam.com
Hi Iran,
you might want to try www.swt-designer.com which also supports JFace
components such as TreeViewer and TableViewer. Telling from a quick
look, Jigloo doesn't seem to support that, and neither does VE currently
(it's on their plan, though).
Iran schrieb:
> I really would like to work with VE, but there are still a number of
> troubles related to hand coding that I can't live with.
>
> Compared to Jigloo (http://cloudgarden.com/jigloo/), VE is still very
> slow on linux and its code parser isn't much tolerant, in other words,
> the code have to look THAT way to be parsed.
>
> On this matter, Jigloo offers much more flexibility. The other VE
> features are OK in my opinion.
>
> So, I have no alternative except wait the next versions before I can
> use VE in a production environment in linux.
>
> Anyway, thanks for the great work, guys.
>
> iran
|
|
|
| Re: Comparing to other GUI tool [message #601685 is a reply to message #67120] |
Fri, 15 October 2004 14:44 |
| Eclipse User |
|
|
|
Iran wrote:
> I really would like to work with VE, but there are still a number of
> troubles related to hand coding that I can't live with.
>
> Compared to Jigloo (http://cloudgarden.com/jigloo/), VE is still very
> slow on linux
I agree that Linux speed could be better. That's true of Eclipse in
general on Linux, but it's very hard to pin down exactly where the hot
spots are. We welcome any and all help here.
One way you can help us is to describe exactly the operations that are
too slow on Linux. For example, "dropping a control is pretty quick for
me on Linux, but typing code in the editor can take a Looooong time
before the status bar says 'synchronized' again." Or whatever it is for
you.
> and its code parser isn't much tolerant, in other words,
> the code have to look THAT way to be parsed.
Can you be more specific? What coding patterns do we not support that
you'd like to see? We're right now in the middle of working on the VE
1.1 draft plan and any feedback you can give us right now is extremely
valuable.
> On this matter, Jigloo offers much more flexibility. The other VE
> features are OK in my opinion.
>
> So, I have no alternative except wait the next versions before I can use
> VE in a production environment in linux.
Thanks for your feedback. We're working hard to make VE better and I
hope that soon it will live up to your expectations. Please help us
ensure that this happens.
Best regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
| Re: Comparing to other GUI tool [message #601777 is a reply to message #67190] |
Mon, 18 October 2004 09:16 |
| Eclipse User |
|
|
|
Ok. I hope I can help with my comments:
> I agree that Linux speed could be better. That's true of Eclipse in
> general on Linux, but it's very hard to pin down exactly where the hot
> spots are. We welcome any and all help here.
I'm ok with Eclipse speed in Linux (I accepted it, :). My comment about
VE speed was when it's compared to Jigloo (take a look on it and you
will know what I mean). It's related to the time VE takes to render the
form when I generate components typing in the editor (it's my prefered
way to work. I'm paranoid about code organization).
>
>> and its code parser isn't much tolerant, in other words, the code have
>> to look THAT way to be parsed.
>
>
> Can you be more specific? What coding patterns do we not support that
> you'd like to see? We're right now in the middle of working on the VE
> 1.1 draft plan and any feedback you can give us right now is extremely
> valuable.
Take this code:
public VETest(JDialog owner) {
super(owner, "Dialog title", true);
initialize();
}
private void initialize() {
this.setSize(400, 300);
this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE) ;
this.setContentPane(getContent());
}
VE shows a warning like WindowConstants.EXIT_ON_CLOSE is too complicated
to be evaluated". So I have to use
"javax.swing.WindowConstants.EXIT_ON_CLOSE", which is unecessary if I
have the "import".
In this example too, after changing the constructor, the first
modification I do in code causes VE to freeze eclipse.
But in later tests, seems like when "blablabla is too complicated to be
evaluated" is shown, a few seconds later VE freezes. So I'm not sure
about it.
In this simple example, sometimes VE takes 7 seconds to render the view.
>
>> On this matter, Jigloo offers much more flexibility. The other VE
>> features are OK in my opinion.
>>
>> So, I have no alternative except wait the next versions before I can
>> use VE in a production environment in linux.
>
>
> Thanks for your feedback. We're working hard to make VE better and I
> hope that soon it will live up to your expectations. Please help us
> ensure that this happens.
By the way, I would like to make a few sugestions:
- minimize the use of qualified names, or at least let the developer
choose the way he wants. In my opinion, use of imports let the code
easier to read.
- let the developer choose if he wants to see the "preview" window (that
separate window)
- make easier access to grid options (show, configure, etc)
Thanks and best regards.
iran
|
|
|
| Re: Comparing to other GUI tool [message #601832 is a reply to message #67320] |
Mon, 18 October 2004 14:01 |
| Eclipse User |
|
|
|
Iran wrote:
>
>
> Take this code:
>
> public VETest(JDialog owner) {
> super(owner, "Dialog title", true);
> initialize();
> }
>
> private void initialize() {
> this.setSize(400, 300);
> this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE) ;
> this.setContentPane(getContent());
> }
>
> VE shows a warning like WindowConstants.EXIT_ON_CLOSE is too complicated
> to be evaluated". So I have to use
> "javax.swing.WindowConstants.EXIT_ON_CLOSE", which is unecessary if I
> have the "import".
This particular problem was fixed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=69675 and will be available soon on a
service stream build. This fix resolve many other problems (see the dups).
>
> In this example too, after changing the constructor, the first
> modification I do in code causes VE to freeze eclipse.
>
> But in later tests, seems like when "blablabla is too complicated to be
> evaluated" is shown, a few seconds later VE freezes. So I'm not sure
> about it.
>
Open a bugzilla with a step by step instructions to recreate this... this is a bug and we need
to address this
> In this simple example, sometimes VE takes 7 seconds to render the view.
are you referring to the code above? Performance is something we really need to focus... but it will
help to focus on particular use cases.
Is this 7sec. on a first time (cold) open? change in the source?
|
|
|
| Re: Comparing to other GUI tool [message #601932 is a reply to message #67421] |
Tue, 19 October 2004 06:16 |
| Eclipse User |
|
|
|
Thanks for your help.
>
> Open a bugzilla with a step by step instructions to recreate this...
> this is a bug and we need
> to address this
How do I do this? I'm a newbie in this matter.
> are you referring to the code above? Performance is something we really
> need to focus... but it will
> help to focus on particular use cases.
> Is this 7sec. on a first time (cold) open? change in the source?
Not just the code above, but any code. It's just a simple one, but in
complex forms this time can increase significantly. This happens in both
situations: when opening editor and after changes in the source.
iran
|
|
|
| Re: Comparing to other GUI tool [message #601986 is a reply to message #67625] |
Tue, 19 October 2004 12:37 |
| Eclipse User |
|
|
|
Iran wrote:
> Thanks for your help.
>
>>
>> Open a bugzilla with a step by step instructions to recreate this...
>> this is a bug and we need
>> to address this
>
>
> How do I do this? I'm a newbie in this matter.
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=VE
>
>> are you referring to the code above? Performance is something we
>> really need to focus... but it will
>> help to focus on particular use cases.
>> Is this 7sec. on a first time (cold) open? change in the source?
>
>
> Not just the code above, but any code. It's just a simple one, but in
> complex forms this time can increase significantly. This happens in both
> situations: when opening editor and after changes in the source.
>
The first time around (cold) start, VE (currently) spends significant amount of time loading classes, introspecting
etc... sometimes it seems as if VE is touching everything on the spindle... we will have to get better at this.
The second time around VE should be much much faster... (warm) open an empty file, is instantaneous in v1.z, and clearly
the more components you have the longer it will take. 7sec. is a long time for a medium (worm start) file. We do
intend to focus more on performance than we did in v1.x.
|
|
|
Goto Forum:
Current Time: Wed May 07 17:06:47 EDT 2025
Powered by FUDForum. Page generated in 0.08469 seconds |
Home