Would be nice for LO to have a few features, which combined will obsolete Dreamweaver: 0) table and cell styles which are currently being implemented, see bug #34391 and bug #38213 1) Split view, and support multiple splits, horizontal and vertical, see bug #31481 2) Tidying up the UI for HTML source mode, see bug #101179 3) Provide an XML source mode editor/ view (the main new feature that this bug calls for - perhaps I am misunderstanding HTML editing mode? IDK sorry, and couldn't find another bug for this...)
interesting idea - thanks!
Ahhh - just found bug #86846. That would be the last piece of this puzzle (I did search, really I did, extensively in fact :). Well, hopefully this bug is considered a useful gathering place for the bugs needing to be fixed and features implemented, for LO to be able to replace Dreamweaver.
what's the problem with Dreamweaver by the way :) ? The name itself is wonderful at least ;)
Adobe DreamWeaver is proprietary software.
Doubt there are any intents of making Writer Web a full fledged gui html editor with a source code modification mode, but lets see what devs think of how difficult this would be to achieve.
If all your requirements have been filed somewhere else why not close this ticket?
Comment #6, there is still the templating side of DreamWeaver - some templates would need to be provided, once bug #101774 (named content) is done. So I guess we could change the bug summary to "provide some Dreamweaver like website templates"; this certainly would be blocked by that.
(In reply to Zenaan Harkness from comment #7) > So I guess we could change the bug summary to "provide some Dreamweaver like > website templates"; this certainly would be blocked by that. I don't see any request for templates in your original posting ;-). Templates are not necessarily provided by LibreOffice and rather user defined objects. You can share them at http://templates.libreoffice.org/. Maybe you are talking about something else, perhaps code highlighting?
Thank you. The guts of this feature enhancement is fundamentally "to replace DreamWeaver" (people use this proprietary software to efficiently make websites based on 'templates' (see below)). At least that "replace Dreamweaver" part is in this bug's summary :) Re 'templates' in this context: the requirement is for DreamWeaver or DocBook like templates (they are both similar) - "entities" or "named bits of content" are the foundation. So for example, bug #101774 (named content) is a dependency. BTW, the libre "DreamWeaver alternatives" available such as BlueFish, do not compare - and I've gotten DreamWeaver users to test BlueFish and other software, but they cannot give up the combination of features that DreamWeaver provides which actually work rather well to create HTML documents/ websites. The feature requests/ bugs that this bug currently depends on to achieve "DreamWeaver replacement status" may well expand in the future: For example, see bug #101788 (split button for display modes - just in today (thanks Heiko)) and which will relate also to bug #31481 (split panes - which are very much part of "the DreamWeaver way"). Also, this bug collects in a single, visible and updatable location, all its dependencies which in this case is not just one, but quite a few indeed; to me, this seems valuable in this instance. Also the documentation of the dependencies "in one location" is valuable (DRY principle - Don't Repeat Yourself) - namely, in this bug, rather than repeating ourselves in each of the dependent bugs with the same various wordings e.g. "this is needed along with bugs a, b, c, d and e... to bring LO up to compatibility with DreamWeaver MX from 2002." Also consider when additional LO enhancement requirements (for DreamWeaver compatibility) are identified - do we update each of the other "dependencies" so they are all linked? This parent bug/feature does that linking in a single consistent location, which is good for tracking the overall status of this long term feature enhancement request. I think all those separate feature enhancement proposals are not only useful, but important in their own right. And once they are done, DreamWeaver is replaced. Being clear on this goal might be useful to help inspire those who have a passion for replacing proprietary software with libre software, to help developing LO :) (Finally, I am new to LO bug reporting, so of course I leave it up to you capable bug curators to make the decisions which are best for the long term of LO - I am really appreciating all the constructive feedback :) )
Zenaan: you are doing good work in the bug tracker, but I'm afraid I must disagree with this particular proposal. Aiming to be a WYSIWYG web editor would be too much sprawl for LibreOffice. Above all: WYSIWYG simply is not a good way to do web design. It is obsolete and we should not invest in it. Maybe some day a revolution will make WYSIWYG relevant again, but that revolution cannot happen on the platform that is LibreOffice (due to the baggage of the codebase). The most reliable and easy way to design for the web these days is to: - use your favorite code editor - view the results of your editing in actual web browsers - use the dev tools of the browsers Instead of adding more, all web editing capability should be removed from LibreOffice. As open source web editors, I would recommend checking out http://brackets.io/ (web-focused code editor from Adobe) https://www.kdevelop.org/ (general code editor from KDE) If still unwilling to let go of the idea of a dedicated WYSIWYG editor: http://bluegriffon.org/ (see "what's inside" for a comparison between free and commercial editions) http://bluefish.openoffice.nl/index.html
For a DreamWeaver like alternative you want an internal document model that is very similar or matches HTML document model. Without this you will constantly have mismatches. Writer doesn't have the internal document model nearly similar to HTML so I don't think it makes sense to push web capabilities further than they are. Actually most of us would be happy if "Writer web" would be removed from LO.
Regina commented the same about the internal model in https://bugs.documentfoundation.org/show_bug.cgi?id=86846#c9 Closing this as wontfix.