You are not logged in.
(was message about Wei's Image Manager)
Does anyone have a source for the ExtendedFileManager? I've been using Wei's ImageManager and would like to see one or the other included in the Xinha distribution.
Thoughts?
Trying to browse the source got this:
Trac detected an internal error:
("Berkeley DB error while opening 'uuids' table for filesystem /home/xinha/repository/db:\nCannot allocate memory", 160029)
Seems to me you need to lock down the Wiki ...
That'll be it!
You want to commit that?
No problem.
NB: Before you commit do a diff on the file to make sure that there are unnecessary changes (indentation changes etc) lest we end up with huge changesets for no reason.
Yea, what I've been doing is two checkouts .. I'll mess with one until I get something right then apply a narrow set of changes to the clean version. subversion rocks.
How about the latest releas example - http://xinha.gogo.co.nz/xinha-latest/ex … ylist.html
Do you get any Javascript errors in the console when trying the nightly?
On my end (Linux/FireFox 1.0) the examples/stylist.html above does not generate any javascript console errors.
I'm using version 1.0.
Latest SVN version (feb 19) works like a champ over here under Linux using FireFox 1.0 , but I do get two errors when running the examples/full_example.html file.
Error: xinha_init is not defined
Error: uncaught exception: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "http://formvista.yml.com/mobie/tests/xinha_dev/htmlarea.js Line: 1339"]
It see how stylesheets are added from plugins, but I haven't found a good example of how to include a new javascript file from a plugin. loadScript doesn't seem to fit the bill or am I missing something?
thanks,
-- Yermo
Should general questions about bugs go here or in the trac?
Question about Bug #12.
After some digging, the bug seems to be in plugins/ContextMenu/menu.css at line 20 where it says:
div.htmlarea-context-menu tr.item td.icon img {
width: 18px;
height: 18px;
}
Commenting out the width and height causes the images to show up, but I'm afraid I don't why. Is it possibly that this style is scaling the ed_buttons image down to 18x18 before the viewport code is applied?
thanks,
-- Yermo
actually i'm not in active development on HtmlArea or Xinha - but some time ago i did....
And venkman is imho the best tool for debugging JavaScript!a config.debug-setting is nice of course too...
Agreed, once you're up to speed. A big problem with most open source projects, this one included, is they fail to realize how important making it easy for people to come up to speed is.
There are countless issues that make a project like this one particularly difficult; countless browser bugs; weird approaches to doing things; a difficult to understand API.
To offset that, it seems to me some focus should be given to making it easy for people to get started ... more comments in the code; some documentation, a debug trace infrastructure so one can quickly see what order things are done in; maybe a knowledge base of browser bugs by browser and version number that have been worked around in the code, etc. You know, all the niggling details that a newbie wouldn't know.
A bit of effort, not much, in this area would go a long way to giving people a safe entry point to the code.
For my own purposes, wanting to contribute but not being up to speed on cross browser DHTML, I'm picking the ContentMenu graphic bug ... while I'm at it I'll comment what I work on and build in the _ddt() infrastructure in the hopes it'll be a step forward in making this codebase more accessible.
Just my $0.02 worth.
Sounds good, you have SVN commit, so feel free to put that in, what I'd suggest is just having a config variable Config.debug (might already be one) that turns this functionality on).
I tend to use alot of debug messages. I build them in as I write or work through a piece of code; so I tend to put commented out _ddtOn() calls at the top of classes to limit debug messages on a class by class basis. Turning on all debug messages at once is an option, but tends to be so verbose that it's not useful.
I'll put it together; you can always nuke it if you don't like the approach.
-- Yermo
Getting up to speed on on the javascript API's and figuring out what happens when seems to reduce down to putting alot of "alerts()" in various places ... kind of cumbersome when one doesn't know much.
Something that I do in virtually every scripting system I build is include a debugging trace facility which can be turned on or off on a per-object or per-file basis.
Then I write a "release" script that strips out all the debug messages (and optionally comments) to create a runtime version. I do all my development on the debug version. I field the runtime version.
I've put together a little _ddt() library that opens up a text area and drops messages into it. I've created a few simple functions to dump objects, HTML and straight messages into the area. It's made it much easier to see how all this stuff works together.
I'm thinking, if one of the goals of the Xinha project is to get more developers on board, having some kind of tracing system would go a long way to making it easier to "get up to speed".
How do you guys do it? Do you actually use the javascript debugger when you're working on code?
Is having a debug trace vs runtime setup something you would entertain? (It's been /extremely/ useful to me as I come up to speed in this stuff).
-- Yermo
To start getting up to speed on DOM javascript, I was investigating the ContextMenu image bug. I'm thinking it's probably a relative path issue (as I mention in the bug report).
When running inside a plugin, what's the current working directory?
Is it the directory containing htmlarea.js or is it the directory containing the plugin javascript code?
The paths used in context-menu.js are "../images/ed_buttons...".
I've got some spare cycles and there are a few items on the trac list I can probably take care of.
Can I simply take over a few of the items or should I go ahead and work on some and send you diffs?
Basically how do you want us to work with you on this? Send in diff's?
It wasn't clear to me how that worked.
Thanks,
-- Yermo
I may be blind, but is there a way to get email notifications when there's activity on a bug I've posted and on replies to my posts in the forum?
thanks,
-- Yermo
Cool. Works now. Thanks,
-- Yermo
Tried to look at the latest SVN submits and got:
[root@xeon tests]# svn co svn://xinha.gogo.co.nz/repository/trunk/ xinha
svn: Berkeley DB error while opening environment for filesystem /home/xinha/repository/db:
Permission denied
I'm on board and I'm willing to jump in as time permits. I can also throw $$ when I don't have enough time to directly contribute code.
I've done a moderate amount of javascript but nothing on the scale of HTMLArea; however I'm extremely familiar with PHP. (and C and C++)
I'm not familiar with alot of the browser API's. Since I've been coding since age 7 I can come up to speed very quickly. At the moment, I have little time so my ability to contribute will be somewhat spotty. However, I'm very motivated because Xinha is extremely important to a large project I'm doing. (details forthcoming)
Initially I figure I can help with testing and provide user-interface feedback; I can also help out quite a bit on the server side while I come up to speed on the browser side API's. Answers to occasional questions will help me come up to speed much quicker.