[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jedit-devel
Subject:    Re: [ jEdit-devel ] Problems with changes to jEdit toolbars
From:       Seph Soliman <seph () mijav ! dk>
Date:       2009-03-21 19:02:28
Message-ID: 3EC50D53-C6AE-4F02-B861-3925F933E1C7 () mijav ! dk
[Download RAW message or body]


On 21/03/2009, at 18.38, Steve Jakob wrote:

>
> On 21-Mar-09, at 1:17 PM, Seph Soliman wrote:
>> I was aware of the API change, which I believe I announced.
>
> You may have time to read and respond to every message that comes
> across on the list, but I don't.
I meant no offense in my statement. If you want we can talk in detail  
about the change over IM or mail. I'll be happy to help you out, so  
the plugin can work again.

> FYI, I'm on the jedit-devel mailing list. There's no need to send a
> copy to the list, and to my personal address. I ended up with 3 copies
> of this message.
The third mail was my error. Sorry for that.

>> I wasn't
>> happy with this, but wrapping the toolbar in a box will defy the
>> changes made.
>
> Why? Box is a subclass of Container, which is what is currently being
> returned.
I tried implementering the toolbar using the existing structure but  
ran in to weird issues with sizing and LNF since the jToolBar  
component is meant to be a placed on the main window, not in child  
elements. Thus, it's not related to the class structure but the actual  
elements that the toolbar is wrapped inside. This is why I changed the  
code.
My initial hope was that the toolbar would end up with some of the  
native features like drag-and-drop, but due to way the UI is  
structured this was a major change I'd rather not make in one commit  
(the textarea and actionbar needs to be changed as well).

>> I'm afraid that your second solution may break more than just the
>> sessions plugin. But I'll have a look at it and see if it's
>> possible...
>
> JToolBar is also a subclass of Container. If client code can work with
> the more generic Container class, there should be no issues with
> JToolBar.
True.

> The change that was most likely to break things is the one
> you've already made.
I don't see how this is true. Any code relying on features  
specifically provided by the Box class would break anyhow. Any code  
relying on the Container class would not break at all. You could argue  
that changing it to jToolBar would be slighty better to give the  
method signature a more appropriate picture of what it returns.  
However it wouldn't help compatiblity in any way as I see it.

But please - enlighten me. If anyone else have problems with the  
toolbar api change please tell me now. Better we get the issues into  
the open, so I can apply a patch that helps the most people.

Best regards
Seph


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
[prev in list] [next in list] [prev in thread] [next in thread]