I'm playing with the now official experimental Dragonfly version – if you haven't tested it yet, please do try it out. Great look, many nice UI touches.
What's even more important: we're also releasing a public roadmap so you can see what features are planned in the near- and long term. From comments on this blog and elsewhere I know that many of your are impatient with the slow development so far – mostly because much of the work needs to be done in Opera's core functionality where we add hooks for debugging and expose required information. It's been a long and complicated process which you've been spared from knowing about ;). The roadmap now gives a pretty clear overview of what features are pending core implementations, and what features Dragonfly should be able to go ahead and implement without waiting for core fixes.
So, a big step forward for Dragonfly itself, and more information about where it's headed.
Suggestions for the roadmap, anyone?
miscoded 
(The code in the screenshot is from a user script I use for debugging. Should perhaps have cleaned it up a bit first :p .)
I've a question about CORE-26037 – it's mentioned in the roadmap by number, but not by name or description (so we've no real idea what was fixed :P).Is it possible with this bugfix to get the user javascript filenames or any script meta-data? Filenames at the very least is 100% a requirement – they seem listed alphabetically right now, but it can still be nightmarish to find the one you're looking for. Meta-data would also be a nice addition…
OK, now how do I get that new version? Changing the URL through opera:config and saving doesn't stick in build 9053.
Originally posted by F-V:
Strange. Did you close Dragonfly before editing the preference?
Originally posted by lucideer:
This bug is sort of a meta-bug listing a number of other issues that should be fixed together. At first glance I don't find any Dragonfly feature bugs here, so feel free to ignore this nugget of information ;)Originally posted by lucideer:
I could not find any bug on showing User JS file names in the Dragonfly UI, please file one. Regarding meta information, I'm not quite sure what you are asking for. How would you like such information presented in the Dragonfly UI?
Anonymous writes:mi biggest gripes are:]]]]]— too late. opera did a great error somewhere in the past not including these hooks and APIs in the first place, and now is paying the big price (i hope that persons responsible will be provided with experimental fast potato). because dragonfly with this speed of development will end irrelevant, it will arrive too late, when web already declared opera not-relevant. (in my opinion this had already happened)— roadmap is very vague, and if this is in fact all, then it is much too little. compared what firebug + yslow or any other plugin can do, dragonfly is not appealing enough to switch from ff+firebug development. and almost no webdevs i know use opera anyway.. look point above— resource profiling (js speed execution/memory usage etc) was declared to go in version 1.0+, this is a bad news, until then noone will use it in serious work, unless forced to, and only you internally are forced to do so.— ability to tell what function was called X times and took XXXms to execute in total.. where is it on the roadmap? different engines do different stuff with different speed, and if system critital loop is very slow in opera it will be very hard to find it— and latest part: when will dragonly be persistent, ie;: not require reloading to get script context (thus destroying debugging context?) when will dragonfly tab/window follow current opera tab automatically and without hassle? just like firebug does..—btw the UI is pretty, icons are very apple'ish, but firebug shows, that you can do much more using much less space and clutter, this should be the goal. if in doubt -> copy from better ones. and firebug ui while not pretty is still the best on the market.—-and while you are at it, because webdevs ignore opera and use a lot of -moz and -webkit css rules, without including normal ones, maybe it is wise to do IF OPERA SUPPORTS_NON_W3C_RULE then CHANGE -moz-something TO something. thre are tons of pages that use -moz-border-radius/-webkit-border-radius and other stuff without including normal syntax.
It works on another install, so I had a look.One of the things I said some four years ago when the developer tools emerged was that we should make them as chrome / proper parts of the browser instead of using web technologies. I argued that was needed to achieve things such as native appearance and behaviour, keyboard accessibility and consistency.I was answered that there were lots of techniques to achieve that with web technologies as well (system colours, scripting to handle focus and keyboard shortcuts, WAI-ARIA….).We're now many years later and this redesigned Dragonfly is still looking unnative as it doesn't use system colours, it is still extremely awkward (in many cases downright impossible) to use it with a keyboard. Behaviour is often different from other parts of the browser or OS.If the intention was to show the technical abilities to do things with web technologies, you succeeded. If the intention was also to show that you can do sane user interfaces that work with you instead of against you, you failed and only showed that web technologies are still extreme hurdles to achieve accessibility and (visual and behavioural) consistency.This whole story goes for the totally visually non-consistent and utterly inaccessible Widgets as well BTW. This web app project also simply screams "not made for accessibility and consistency" even after all those years.I know, and only expected, that the world's web authors would not all be able to cope with all these challenges in the vast possibilities that current web technologies have to offer. I only hoped that some more evangelizing could come from a company such as Opera itself, by being a leading example instead of following the easy and inaccessible way.I know this comment is extremely single-sided, but as accessibility and sane UI design are the side I'm most critical on I simply can't give any positive note here and can only stress the enormous missed opportunity and the signal it gives for "Web 2.0".
Originally posted by anonymous:
Can't argue with that, would have made my life much easier if Dragonfly had been available, say, 8 years ago :pHowever, we would need a time machine to fix that. I'd prefer feedback on things we can fix without time machines, going forward 🙂
Indeed. This must be on the roadmap.
That's not an easy request – enabling debug mode will slow down the page, and if you've got 100 tabs open and want to debug one of them it doesn't make sense to slow down the other 99. I don't think this is possible without some speed/memory usage trade offs that we would rather not make.
Well, that would have to be an optional feature. I like the current behaviour – much easier when I'm debugging one tab while looking up information or writing bug comments in another.
Can you be more specific about what you think is using too much space or is too cluttered? Specific feedback on this would be great.
Originally posted by Hallvord R. M. Steen:
For the record, Firebug seems to make the same speed vs. functionality trade-off (which is perfectly acceptable to me; I'd rather reload things once than slow down all my pages all the time).Originally posted by Hallvord R. M. Steen:
Loooking at the screenshot (haven't tried the new testing version myself yet) there's these huge icons compared to the text-based labels in my current version of DragonFly (and Firebug). Other than that it seems fairly equivalent to me GUI-wise, but I find DragonFly easier to use for CSS debugging tasks primarily due to the way the element highlighting works.
Originally posted by hallvors:
A ruler in the utilities (or grid, grid sounds better, now) and a color picker http://www.quackit.com/css/css_color_codes.cfm For the Network tab, could there be a nice summation of how long things took to load, as seen in Chrome's debugger?(To save loading time, maybe have those things be loaded after dragonfly starts up.)I can do a mock-up of the grid if you want, I thought of a way so it doesn't look ugly, although someone has probably done it before.
Some things I see (with this release and DF in general):Resizing any area in Dragonfly with the mouse uses 100% cpu. The resizing is not very efficient. It should be as fast or faster than resizing an iframe, which is super fast in Opera.At 800×600, the icons up top take up way too much height. It also doesn't help that there's like 5 toolbars taking up height before you get to the DOM content under "Documents". Lots of space is taken up leaving little for the content sections.Also, only individual sections in the dragonfly window scroll. If the window is smaller than the contents of the dragonfly page, many parts of dragonfly become inaccessible. The whole window should scroll too when needed.Can't select and copy the addresses of scripts, or at least right-click and choose "open in new browser tab".Under "Network", when I expand a request, I'd rather have it display "raw" by default. It's much much cleaner. The other views are way to chaotic with icons and spacing and such.There's a redraw issue with the inspection area under "Scripts". Quick find and the buttons are chopped off.With WinXP's "Group similar taskbar buttons" turned on, it'd be nice if the dragonfly window (and the error console window) differentiated themselves so they're not grouped with the main window's taskbar button. Makes switching back n forth a pain.In the windows panel, it's not possible to drag the DF page/window into the main windows as a tab. Really want a DF Tab by default. Haven't tried loading the DF URI in a tab directly in a while though.Although there's ctrl + shift + i, the DF option in the Menu is way too deep. You can of course fix this by adding a dev menu. But, if you also have other, separate menus, this can get crazy as you have to start duplicating things. That's why there should be a dev menu by default (that's not way deep). Maybe sections in the menu and toolbar ini files can be hidden by default until you enable opera:config#developer_mode or something.With the JS console in dragonfly (when it's in a window) sometimes I want to use the console to run JS and alert()s. But, the alert()s open up in the page instead of on top of the dragonfly window. I understand why, yet, I'd still like the latter sometimes. And, I'd sometimes like to use the console to run JS as not part of the page. Just an interpreter.In short, I still cringe when I use dragonfly. It still doesn't feel native enough and doesn't seem very integrated into Opera. It still feels like a limited web app. Of course, it's better than nothing. Yet, I still do things the hard way as I don't really like the UI of dragonfly at all. I'll try harder to get used to it.
Originally posted by DanielHendrycks:
Safari also has that (so it might be a webkit thing) It has colored bars representing different kinds of content that was loaded:dragonfly:
Originally posted by Hallvord R. M. Steen:
I have no idea whatsoever. My main issue was the lack of names, meta just cropped up in consciousness while typing. I actually wasn't really talking about Dragonfly or the UI though – I was referencing that bug as I assumed it was related to Scope and the various information provided by Opera's core – that info doesn't necessarily all have to be used immediately by Dragonfly, but it can still be provided. Isn't that why Dragonfly is open-source and Scope is documented?Originally posted by Hallvord R. M. Steen:
I think I can agree with most of (possibly all of) what burnout426 said above.. but I'll take the time to give a detailed response of my own in a while.Originally posted by Hallvord R. M. Steen:
Will do.Edit: Actually before I do – as mentioned above I was really more referring to Scope and the API, rather than the Dragonfly UI. I'm wondering if user javascript filenames are available via the API. If not, I'll file a bugs.opera.com bug, if they are I'll file a bitbucket issue for implementation in the UI.
Anonymous writes:more specific feedback: firebug CAN follow tab changes without visible performance penalty with 100+ tabs open. I do it all the time, and really never felt a need to turn it off. so it can be done, just please do it. Firebug also is immediately useful after launching it – so, again, it can be done. just please do it. This sums all opera excuses about this topic ive heard – it can be done, and excuses provided simply do not hold water in my opinion. it can be done, it had been done before, so just copy it, until then people will avoid it. |||| UI.. opera, again, made a great error trying to reinvent the wheel when designing dragonfly UI, it was before opera had any good UI/UX designers and it can be seen. you should have copied firebug UI, and this request still stands – just copy it! it is simple, it is very clean (no useless fancy icons!!) and 99% of world webdevs know it already. just freaking copy it. i also agree that this looks like unsuccessful attempt to persuade people, that web technologies are enough. they aren't. it should have been done in native GUI, with native colors, with native fonts. features that are missing from the roadmap: js performance profiler, multiline console, resource usage profiler, support for non-opera css declarations (-moz, -webkit, spelling mistakes, illegal values), picture preview in css/dom inspector, larger color previews, usefull js debugger, and that tool you yourself had to substitute with your js snippet pictured above. and for heavens sake – please, please add ctrl-f5 that every other browser have – FORCE reload, ignoring cache etc. simplest thing that makes one do stupid things, becaue opera 'doesnt see' changes. turning off cache isnt a solution.. oh and the last thing – where is the place i can see global objects? all i can see is dom properties of html objects? in general – dragonfly still FEELS unpolished, clunky etc. and this 'reload' stuff is a showstopper that makes using it a pain. and people doing this for living would like a tool that does not hurt to use
Originally posted by anonymous:
Wait, are you saying Firebug does this?
Both Safari and Chrome (and Blackbarries new browser) are based on webkitI do also like that other browser in the source code have line numbers
Originally posted by Charles Schloss:
Yep, that is what I am talking about. (Wouldn't know, installing safari means I have to clean up the mess of it's other apps it likes to install with it)
Originally posted by Charles Schloss:
A fork needs to be used (Apple could easily just start charging royalties) or an adequate engine must be opened.Originally posted by Charles Schloss:
+1, browser specific, not something the engine provides, I believe
Anonymous writes:"Wait, are you saying Firebug does this?" – no firebug doesnt do that (all tools enumerate over objects and if engine doesnt show something, then it isnt there). but dragonfly should have at least one thing more than other tools (remote debugging doesnt count) and this would be a nice thing
Originally posted by anonymous:
Gotcha.
Originally posted by hallvors:
Thanks for that line of thought. Right up my alley. Would be awesome if we could set a debugger flag for specific sites, or can userjs invoke the call?For the guy with reloading issues, I though F5 was already supposed to ignore the cache? Or is that changed/broken?From the creenshot above, UI would be much smaller if you placed mode buttons into menu toolbar on right side. Or more likely mode goes top left, menu top right. I am definitely with who feel that large, pretty icons are outweighed by the premium on real estate. (especially often using a netbook on the go) One crazy-awesome thing would richer support on "view source"/apply changes. If "view source" had a small selector pane, which allowed the picking of elements to edit. (especially all that damned embedded scripts, truly encapsulating a cached pagestate would be awesome)An engine improvement that allows the export of a loaded page, by bundling cache files with a master cache document?I am glad Opera's "Info" pane can be locked, but nested Iframe data would rock. As would richer media information. The only thing I ever missed from Firefox, was that window listing embedded media files. I understand that much of this does not fall under Dragonfly proper, but it would enhance the experience quite a lot.
Anonymous writes:"For the guy with reloading issues, I though F5 was already supposed to ignore the cache? Or is that changed/broken?" |||it was never fixed in my opinion. there is still no way to do a FORCE reload, ignoring all cache control etc. and that hurts
Originally posted by anonymous:
Yeh, I'm pretty sure it's not right either. Mabye setting things to "Always" under "Ctrl + F12 -> Advanced -> History" while testing would help.
Ctrl-F5 noted, will be implemented (for the record, it's bug CORE-32618). Not really about Dragonfly though ;)Back on topic: thanks for all the other feedback, I will try to get an overview of what is and isn't planned/bugged. I might report some bugs where I agree with a request that wasn't already reported ;). I will post an overview as a comment here or a new post, depending on how much data there is.
I forgot to add that I also find it awkward searching in dragonfly. The main thing is that F3 doesn't act as "find next". Instead, you have to keep pressing enter. There also doesn't seem to be a "find previous" function. I tried shift + enter, but that didn't work. But, it should be shift + F3 anyway. I also find it lacking that you can't trigger a search with / or ctrl + f.
Anonymous writes:hi. Is there any due date for your roundup?
Originally posted by anonymous:
No, sorry, it is scheduled under "when I get to it".. Perhaps mid-next-week or so.
Anonymous writes:ok 🙂 thanks for your time to reply and no rush
:right: