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

List:       quanta-devel
Subject:    Re: [quanta-devel] my tool would be like this...
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-04-08 20:59:34
Message-ID: 200504081359.34279.sequitur () easystreet ! com
[Download RAW message or body]

On Friday 08 April 2005 06:57 am, Paulo Moura Guedes wrote:
> On Friday 08 April 2005 06:09, Jens Herden wrote:
> > > and the style would be manipulated in
> > > two ways: using direct HTML or in an external (CSS) stylesheet, by
> > > clicking on the tag name box.
> >
> > A CSS editor in a toolview would be smart. But there are unlimited
> > positions for CSS information:
> > 1. tag
> > 2. file
> > 3...n external files
> >
> > To make a real good CSS editor is a challenge I guess.
>
> I think it's impossible to consider all this options. We should restrict to
> edit in external files. It's the responsibility of the user to make sure
> there's nothing overriding the external CSS file settings. I think it's the
> only way to go.

Are you saying that you don't want to allow a span tag? In my opinion, as 
complex as this is, as soon as we begin to say that this is the only one way 
to do things we begin reducing our audience. It's one thing to encourage or 
support first or preferentially but to say that we will not support what is 
both valid and probably common means we should consider an import filter that 
harrases the user over stuff we don't like doing. ;-)
>
> > > I don't know if it's feasible to show the style of inline text nodes
> > > and the arrangement of elements after been processed by CSS, at least I
> > > don't know how. Displaying just plain text would be enough (what about
> > > images...)? BTW, how to implement this? :) Maybe we need to have our
> > > own canvas where we would draw the block node structure and insert
> > > KHTML render fragments inside the block nodes scope (in case we didn't
> > > have just plain text)? This is a little crazy I know :)
> >
> > I also was thinking about using KHTML to render the textboxes too.
> > Reading you text lets me think if we could switch between preview mode
> > (KHTML) and edit mode. Edit mode would be text only and additional
> > indicators for the tags.
>
> I like that.

This is the type of visual feedback we need to look at and determine what is 
best. Ideally we determine a subtle but obvious method and this one sounds 
good.
>
> > Images are inline elements so we have to show them somehow, maybe just as
> > thumbnail or an icon with tooltip that shows the image? And a doubleclick
> > could open a dialog with the original size and ways to change the
> > attributes. But the size can also be in CSS and I don't know if it is a
> > good idea to offer a way to resize an image and adjust the CSS
> > accordingly?
>
> We could have a checkbox asking wether the changes should be written in CSS
> or HTML.

If he's talking images inline in CSS I'm not so sure.
>
> > > So, this approach has the advantage of easy manipulating the structure
> > > and having a more intuitive display, but at the same time is difficult
> > > to imagine how the document will display. It would be a complement
> > > view, as we also need things like dragging absolute positioned div
> > > elements and resizing images.
> >
> > As I wrote, I do not see the need for being close to the result. Just hit
> > F6 and you know. Or let us make a live preview in a toolview that can be
> > seen during editing.
>
> It's a little like latex editors isn't it?

I okayed Jens' post for discussion, even thought there are things I don't like 
about it. Frankly I don't like the idea that what you have in VPL would not 
resemble as much as possible what you're working on. Yes, you can switch to 
preview, but you can do that in text mode too. However the paradox is that 
VPL by definition cannot be exactly like the rendered HTML or it will not 
provide visual feedback.

So what Jens is saying makes sense if you're trying to just get stuff entered 
in the general area and with approximate format. However once you are trying 
to do precise absolute layouts or edit visual styles this proposal tends to 
fall apart and not b any better than text mode. In the end we determine the 
usefulness of VPL by what uses it can service and by how efficient it is. 

I like Jens' ideas where they can be applied to create efficient use and not 
remove usefulness of some uses. Here are some other ideas to mix in...
* create a visual tree like what Jens suggested as a side panel thumbnail view 
instead of the structure tree Moura suggested
* enable visual alterations and mode changes only upon selection
* enable a "sub-VPL" quick layout mode
* make the visual changes work from context menus to show an area with a 
highlight mode
>
> > > I would say this is kind of a merge between the kafka part and the
> > > document structure. It's hard for me as a user to imagine how good such
> > > a tool could be but I would like to further discuss this ideas. I think
> > > we're heading in the right way and will take good conclusions out of
> > > all this.
> >
> > Sure it is different from VPL and I think this is something we can
> > implement when we made the switch to KDevelop framework.
>
> When this move are expected do you know?

You're looking at this as an alternative already?
>
> > I would like to
> > see many different plugins that all together create the functionality of
> > the current Quanta. So adding a new edit mode would be writing a new
> > plugin and the users have the choice what to use.
>
> So this should only be started then.
>
> Good work Jens, this is an excellent idea!

Yes, if we can maintain a diverse usability and incorporate this into things 
without making it a constraint it has a lot of promise.

BTW I apologize if I missed anything because I'm rather busy and not getting 
everything thoroughly read.

Eric
>
> BTW, I'm studying the chance of adding MathML support in Quanta. It seems
> that KHTML supports it. I didn't start to think about this in depth yet but
> I though maybe you people have something to say :)
_______________________________________________
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]