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

List:       quanta-devel
Subject:    Re: [quanta-devel] VPL toolbars
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-03-09 6:43:12
Message-ID: 200503082243.12322.sequitur () easystreet ! com
[Download RAW message or body]

On Tuesday 08 March 2005 08:11 am, Andras Mantia wrote:
> On Tuesday 08 March 2005 18:01, Paulo Moura Guedes wrote:
> > On Tuesday 08 March 2005 15:42, Andras Mantia wrote:
> > [...]
> >
> > > But I don't like the idea, especially if in the long term you want
> > > VPL to be not HTML specific.
> >
> > Can you elaborate on that, I'm not seeing your point.
>
> I say that if we support docbook for example in VPL, will we create a
> set of docbook toolbars for source and another set for VPL? Doesn't
> make sense for me.
>
> Andras
I agree with Andras, but I know what's frustrating Moura, and I've said we 
should do something about this at some time. Here is one thing I think is 
central to what is wrong and Andras I think you should consider this more 
because as yet you have been less than enthusiastic. 

In VPL we need to insure that what we do is 100% compliant, both because we 
want to be compliant and because variations add complexity. Our toolbars 
currently add tags as mere text blocks with some basic ability to handle 
simple XML rules, and while this is generally okay it creates a mess with VPL 
and doesn't make sense with our general design. They also add an irrational 
redundancy for users and constrict one idea I've had to make them more useful 
for DocBook. Following are problems.

1) If I want to add a tag for a DTEP I have to define it. This is in contrast 
to the design imperative of Quanta to do the most work in redundant areas for 
users and provide the most efficiency. This also opens up the possibility of 
errors, but it is the fact that when I am working I don't want to be 
distracted for any length of time to improve things. I want improvements to  
be as painless as possible because I don't have time to do a cost benefit 
analysis on whether it will save me time.
2) The idea that these toolbar buttons may be enabled and disabled in context 
is a nightmare because in the scheme of our design they are a relic of 
meaningless disconnected data. Dealing with this means establishing 
connections and complex rules for VPL which duplicate our already rich and 
useful DTEP.
3) If we wanted to add a picklist type menu of tags to a toolbar it would be 
very difficult because we have no way to do this.
4) If my toolbars were tied to my DTEP so that adding a button would access 
DTEP information we could possibly reverse this for custom DTEPs so that 
adding a tag not in the DTEP could enable a dialog to help define it in the 
DTEP. This way creating an XML dialect for data for instance might help to 
generate a DTEP or DTD->DTEP on the fly, which would be very cool.

I've said before that a picklist like menu, similar to the dropdown menus on 
some toolbar buttons, would be very useful for something like DocBook. 
Regardless the benefits for VPL from generating a contextural relationship 
between toolbars and DTEPs would be be significant, and it wouldn't hurt text 
mode either.

Currently we can create new button Actions as 
* Tags
* Text blocks
* Scripts
What I propose is to add "DTEP linked tags" and make them the default. So we 
have the following:
1) DTEP tags - always active, contextural in VPL, optionally contextural in 
text
2) old style tags - always disabled in VPL
3) text bocks - disabled in VPL, these can be replaced by templates in 
standard use anyway and the templates can have information about what their 
top tag block is so that they can be used in VPL
4) scripts - this is a can of worms in VPL so I leave it to the more 
ambitious. ;-)

Eric

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread]